Network-based Local Mobility Management (NetLMM) TUESDAY, March 20, 2007 0900-1130 Morning Session Chairs: Phil Roberts Vidya Narayanan --------------------------------------------------------- PRELIMINARIES (10 minutes) Agenda review Blue sheets Notes and Jabber scribe WG status Rough consensus to standardize MIPv6-based solution Very rough consensus on terminology LMA, MAG, RHoA, PLCoA Consensus call in progress to adopt WG document AR interface draft has expired, still waiting on terminology SDO Update Liaison letters received from WiMAX and 3GPP2; request from 3GPP for PMIPv6. All correspondence is now posted on the list. ALl SDO requests are treated as input for requirements. SDOs encouraged to participate in the WG as individual contributors, and to read and provide comments on both candidate documents. We do not have an official relationship with WiMAX. IPR Status Third party disclosure prior to San Diego, then disclosures from various companies. Links to IPR disclosures. Qualcomm has yet to respond. Preliminary judgement is that it doesn't apply. After all disclosures have been reviewed, we will ask again whether WG wants to move forward. Recap of agreed goals "No changes to HA" is NOT a goal Minimal changes to HA are acceptable, not a limitation in doing the right technical approach. IPv6 global addressing model is based on prefix-per-MN Protocol MUST comply with the goals and threats documents. SDO specific optimizations for the protocol are out of scope mic: minimal changes, what does that mean exactly? Vidya: tough thing to quantify. Don't want a brand new box with no resemblance to an HA, but will be some changes. mic: can we decide to defer the MAG compromise issue to operators Vidya: has been documented in the threats document PROTOCOL DRAFT PRESENTATIONS (30 minutes) Topic: A Protocol for Network-based Localized Mobility Management Presenter: Ajoy Singh Time: 15 mins Draft: draft-singh-netlmm-protocol Submitted prior to the last IETF meeting, more than 1 year old. We saw some differences. Basic operation PMIP client is standalone, sends BU to LMA (HA), uses altCOA to hold MAG's IP address. Signaling and bearer are decoupled. Same PMIP client sends next BU, same SA is in place initial attachment Call flow Trigger, notification between MAG and PMIP client Inter-MAG handoff Trigger from MAG2, PMIP client sends BU, then sends notification back to MAG2. Supported features Initial attachment Intra-LMD handoff Separation of PMIP client and MAG functionality Security association between PMIP client and LMA Features discussed in appendix comparison of two architectural concepts PMIP client anchoring Standalone PMIP client PMIP client relocation PMIP client is co-located on MAG PMIP client moves with mobile node from one MAG to another Anchoring Allows separation of data forwarding (tunneling / de-tunneling) Similar concept as WiMAX for MIPv4 PMIP client can be implemented on a node that is secure Simplifies service management (e.g., billing) by providing a single service triggering point Security Associations: SA between PMIP client and HA is done only once, handover performance will be faster. Re-use of RFC 3775 HA. Summary Proposal: draft-singh describes PMIP client anchoring draft-sgundave can be enhanced to provide PMIP anchoring Can consider both approaches to have a role in base draft Topic: Proxy Mobile IPv6 Presenter: Sri Gundavelli Time: 15 mins Draft: draft-sgundave-mip6-proxymip6 Main Protocol features supported in the draft Recently published -02 version Moved shared prefix model to appendix section (using DHCP) There are some issues with shared prefix and autoconfiguration, so it was removed from the draft. Dual-stack nodes, dual-stack network IPv4 transport including NAT traversal Stateless or stateful configuration LMA to MAG trust. LMA knows there is a certain node in the network authorized to do certain things. Link types between MN and MAG can be shared or p2p. Model in SDOs is p2p. We wanted to support shared as well. Added scenarios for combining local and global mobility; some scenarios in the appendix for co-located LMA and HA. If MN does DHCP, what is the function of DHCP relay agent on the link; how do we make sure the MN gets the address from the right prefix. Tunnel between MAG and LMA can be shared. Illustration: Proxy MIPv6 Domain MN moves from MAG1 to MAG2, two tunnels back to LMA How we break up MAG function is not specified. Nothing stops you from breaking up MAG into two nodes Changes in -02 version Discussions with many people Terminology changes shared prefix model to appendix Time-stamp option details and relaxed the MUST requirement for this in the PBU; can use sequence numbers if context transfer is in place Generic MN-Identifier instead of NAI Added IPv4 transport network support, leveraging DSMIP6 work Clarified mobile node modes: v4, v6, dual-stack. Gerardo will cover later Open issues IPv4 support in base? Integrated Mob Management scenarios, co-located LMA and HA? How do we determine ordering of BUs? Timestamp is a good option. Access Link need a domain-wide DAD? If DNA is implemented on MN? Do we want to have a split model? We don't want to specify it. Do not want WiMAX R4 interface. MAG might become single point of failure. Function can be broken up. IPv4 UDP support might be broken. Wrt changes in HA: there are still changes required for per-MN prefix model Download the keys: in split architecture Ajoy: NAT traversal. In our draft, PMIP client can be located on MAG. just anchor it on MAG. Then there won't be any issue with NAT traversal Sri: initially the PMIP client will be fixed. You are still sending messages back to previous link. Ajoy: no, anchor PMIP client, will go through same MAG, so no issues with NAT traversal Sri: no, if there is a NAT between MAG-1 and HA but not between MAG-2 and HA, then NAT will not create binding for new address. Ajoy: can be addressed. If there is a NAT, Sri: NAT binding has to be created on NAT box, cannot force the message on a particular path Ajoy: NETLMM is localized mobility management protocol. Should cover a particular domain, this is a corner case Sri: no it's not Ajoy: CSN/ASN can be split in WiMAX Sri: don't understand Vidya: we are going to have a IPv4 discussion later Vijay: Many of the claims were completely bogus. Ajoy: all the claims have been discussed on the mailing list. you are welcome to comment. I don't believe all the claims are bogus. Vijay: one example. Security Associations: biggest advantages of using new security model in MIPv6, is to re-use SAs between 2 network elements. They are not per-mobile. That is an advantage. There is no need to establish IPsec at handoff time. You just set it up once. Ajoy: I agree. The point is that there are 2 issues: authentication and authorization. Vijay: talking about authentication not authorization Ajoy: Even in the case of authentication, you can set up tunnel in advanced. In CSN/ASN split, cannot assume there will be a static SA. 2nd problem is authorization: very critical. In draft-singh, it is done during initial attachment, will reduce handover delay. Vidya: keep SDO-specific discussions out and focus on what we are doing here. It might confuse people. Ajoy: sure, draft is not specific to an SDO. Pointing out, WiMAX NWG has already specified PMIP. AlexPetrescu: 1st presentation for draft-singh. There are several good features, some are required by SDOs. Separation of fowarding and signaling should be included in base draft. Draft-sgundav, there is NAT but we don't know clearly why we have NAT there, and we don't know in what direction that NAT is. For DNA, there are comments on ml saying there are no NAT issues. Sri talked about GRE. Nobody asked for GRE. Don't want to call any points raised bogus - we can expect clarification. Sri: NAT: HA is behind one NAT but not the other. Alex: NAT could be the other way, why did you put it that way? Sri: just showing a scenario where it breaks We are just re-using DSMIP solution Alex: we need to give operators flexibility Sri: we wanted to put GRE in base draft Alex: why didn't you consider other encapsulations than GRE? Vidya: we will discuss open issues later, including IPv4. Let's not spend times on those issues now. AhmadMuhanna: Authorization bullet you have to take it out. It isn't valid. Unless you are talking about PMIP relocation. It is not applicable to Sri's draft. SA is not applicable, authorization by next one. Ajoy: qualify here: SA between MAG and LMA you don't need to do that, but if they are in different operator domains you may need to. Ahmad: said one PMIP client serving several MAGs is an advantage what about single point of failure? Ajoy: PMIP client can be separate or integrated with MAG. Ahmad: oversimplifying. If you have PMIP client in every MAG, cannot guarantee that one MAG isn't going to be overloaded. If one is overloaded, all control is on that MAG even when moving to other MAGs. It could generate a point of failure. If a mobile on MAG 10, control on MAG 1 goes down, how can you communicate to mobile that connection is down. Ajoy: anchor as much as possible Ahmad: q to sri: in version 2, you put sequence number and timestamp, are you planning to address both? Sri: yes Gerardo: 2 questions, 1 comment. Ajoy: MAG and PMIP client, there is TRIGGER message. How does the MAG know the PMIP client address? Ajoy: PMIP client can be located on 1st MAG (local message), or standalone box MAG will have knowledge of that box. Like ASN gateway they will know about each other. Gerardo: don't want to talk about 3GPP there is a system in IETF we don't have system. Preconfiguration: is this per MN, or one per PMIP client? Ajoy: you can hash the PMIP client based on MN. You can also use DNS-based discovery. Use the same process on each MAG Gerardo: ok, but your draft doesn't specify anything other than preconfiguration To sri: draft specifies DHCP messages, trigger. To Sri & Chairs: we have MN/AR interface draft. When we wrote the charter, how the MN handles that is part of that specification. Let's drop from base specification Phil: basically right, although, if there is something needed for base protocol to operate MAG behavior, will need to go in base protocol Gerardo: DHCP is one way, there might be others. On authorization: need to clearly understand what we are talking about. Are all MNs in the network authorized to use Proxy MIP? If we assume any MN attached to the network is allowed to move, Proxy MIP is a service like a routing service, then per-MN authorization is fine. If we want to say that some nodes are authorized, others are not, then you need some per-MN information per exchange. Q for the WG. Sri: Policy based thing. If the MN is authorized, then logic of advertising prefix is used. Kuntal: clarify: there will be per-MN ID in the PBU. So if the LMA wants to authorize per MN it can do that. Vidya: we are running very late let's move on. PMIPv6 OPEN ISSUES - DISCUSSION (105 minutes) Topic: PMIPv6-MIPv6 Interactions Presenter: Gerardo Giaretta Time: 30 mins (Presentation:5-10mins; Discussion: 20 mins) Motivation: long discussion on how MIPv6 and PMIPv6 can be used together. One of the reasons we chose PMIPv6 was to cover scenarios where they are used together. Objective: identify main scenarios and open issues. Requirements on MIPv6 and PMIPv6 solution to make it work. Issues are generic. Just wanted to list all possible issues that a draft must solve. Need to understand whether we support those scenarios in the base draft. Three main scenarios: 1. PMIPv6 is the local mobility management protocol, MIPv6 is the global MM protocol. 2. MIPv6 terminals and "PMIPv6 terminals" in the same network 3. Movement between PMIPv6-enabled areas and non-PMIPv6 areas. Scenario 1: illustration. HA behind LMA. Address assigned from the PMIP LMA is used as the coA for MIPv6 BU No real issues, except one that may or may not be real: Possible race condition between PMIP registration and MIP registration. Vijay: MN can't send a BU until it gets a CoA, CoA comes from LMA. You always have sequence where MN attaches, then Proxy BU/BA happens, then that becomes CoA. So no race condition. Gerardo: may have situation in bootstrapping. Scenario 2: Two kinds of terminals in the network Node that implements MIPv6 doesn't want proxy. Looking at drafts now, there is some idea that network is advertising the home prefix to the MN. Solvable at system level, if we have AAA or user profile that tells the MAG whether or not to trigger PBU. Out of scope of this WG. Raj: mentioned that home link is advertised to MN, not in context of this WG to say whether MN should use this prefix or not. In that case, MN may not be aware of whether it is really attached at home or not. If real MIPv6 MN, can just get a CoA does not know whether PMIP is in use. Gerardo: if you have some profile in LMA Raj: can't really say that in the profile. Host might change. Can't really say what capabilities are in the device. Gerardo: may be some cases where the profile indicates. Phil: let's see the whole presentation before further comments Scenario 3: Movement between PMIP domain and non-PMIP domain CoA configuration MIPv6 BU MIPv6 HoA is the address used by the MN in the PMIPv6 network. Note that there may or may not be PMIP in the new domain, point is that LMA is different. Issues that may or may not be solved in either draft Security Assumption in 3775 that there is a binding between SA and BCE. In PMIPv6 this is not true any more, at least in some draft. Different SAs used to update the same BCE. Compromised MAG can send a bogus PBU to the LMA HoA management and lookup key in BC HoA may not be in the BU and may not be in the BC. We decided on per-MN prefix, so HoA is not needed anymore. In 3775, HoA is used as the primary key to find the BCE. Moreover, when moving from PMIP area to non-PMIP area, MN will send a BU for a single HoA. Maybe HA will not update the old entry based on home prefix. Going the other direction, then you need to handle the registration of the PBU will not update the MIPv6 BCE. Race condition between registration from MAG and de-registration of the MN Solvable, but need to understand what is the best way Sequence Numbers Some versions of PMIP use timestamp not sequence numbers. Need to understand how sequence numbers and timestamps are used. Multihoming An interface in the PMIPv6 network and another interface handled with MIPv6 Some areas overlap with MONAMI6 Conclusions No issues with Scenario 1. Scenario 2 is out of scope. Scenario 3 Several issues for movement between PMIPv6 and MIPv6 may be solvable Do we need to do this now in the base or leave for future work? Hesham: general answer to comments: 50-60% of scenarios need to be explained a bit more. Don't see where the problem is. Is there a draft? Gerardo: no. Hesham: need to spend more time to see if there is a problem. On security slides: don't understand. 1st 3 bullets say that it is different, 4th bullet about compromised MAG is true of any routing element Gerardo: yes, trust model is same as routing protocol. What I wanted to say was that here we are talking about PMIPv6 MIPv6 interactions. We are changing the security model of 3775. Vidya: question about routing protocol equivalence. If one entry is compromised, routers can still work as long as one route is working. In mobility protocols, can only update that one address. In proxy MIP, compromised MAG can continue updating binding even after MN has left the domain. Hesham: if it left the domain, does it still have the home address? Vidya: it was at home in the PMIP domain Gerardo: address managed by PMIP is the home address Vidya: 2 cases: one where PMIP assigned address equals the MIP CoA. 2nd: LMA and HA are co-located Hesham: why would you do that? Vidya: good question Gerardo: Hesham: why would you create a scenario that is so complicated? Gerardo: there are some SDOs that are creating it. Vidya: Phil & I asked people to do presentations on open issues. there has been a lot of discussion on ML about supporting this scenario Kent: Initially, thought this was a PMIP threat model document which is already published. Ajoy: If you anchor you don't need multiple SAs. Compromised MAG: if you do anchoring, deep in the network can be more secure compared to MAGs on the edges. Gerardo: you are just moving the problem. In your proposal there is a trigger from MAG to PMIP client. Trigger can be used by compromised MAG. Ajoy: can be l2 messages. Since 3GPP2/WiMAX L2 is not discussed here. Vidya: let's not discuss SDO issue In threat model document, only discusses security in local domain Hakima, IIT France: Charter? is there any performance for PMIP, does it perform better that HMIP? Phil: charter is just in a local domain, but there might be issues here Vidya: in San Diego, we decided to focus on PMIPv6, so now there are interactions Gerardo: should ask authors of PMIP drafts about performance. Vidya: not in scope of this discussion Hakima: is solution going to be based on MIP? From performance point of view, it might not be good for NETLMM? ? from ETRI: mip6 extensions, NEMO should be considered for these scenarios Gerardo: assumption was to start with 3775. If we identify that to handle these scenarios, need 4285 or MONAMI extensions, then we need to decide whether to take these on. Kent: clarification: this Gerardo: issue does not apply to PMIP-LMA, but to MAG-LMA Vijay: good set of slides. Scenario, we need to work on this somewhere, interactions with MIPv6, NEMO, etc. We should write the base protocol so that it allows this but shouldn't put all the details in the base protocol. We could do this in a separate document. We have to address this. Gerardo: If there are requirements in this solution, should we include now in the base spec? Suresh: Does MN get a choice about whether to do PMIPv6 or MIPv6? There should be mechanism to choose. Gerardo: this is the 2nd scenario, we should consider it out of scope it is a system level consideration. Raj was not agreed with that. Agree there is a problem, not sure whether needs to be in base protocol. Sri: can extend the RA Vidya: identified scenario as out of scope of base draft. Sri: needs to be in ND specification somewhere. Suresh: once I send an RS, signaling is done Vidya: take it on the list EricNjedju: chairs suggested we stick to IETF architecture here. How do you resolve this with inputs from SDOs? Phil: nature of the relationships is that we communicate about expectations. Actual work is to be done in WGs according to the IETF process. Some people are constituencies of interests. We can take it into account as individuals contribute. Eric: PMIPv6 will not run on its own, it will always run as part of a system. It is not always possible to design in isolation Gerardo: we cannot specify a system here SDOs will make their own choices. Eric: Discussions were about systems. If there are functions in the 2 drafts SubirDas: support Hesham's comment that it would be nice to have a draft. What is PMIPv6 terminal? Gerardo: It is an IPv6 terminal, where mobility is handled via PMIPv6. Topic: IPv6 support (link local and global addressing, DNA interactions, etc.) Presenter: Julien Laganier Time: 30 mins (Presentation: 5-10mins; Discussion: 20 mins) per-MN subnet WG consensus for IPv6 Has some implications we need to discuss here. Issue 1: Multicast RA on shared links. Unicast RA sent to RS's source link local address source of RS MUST be link-local address (DNAv6) But do we have DNA? Not clear. Issue 2: discovery of on-link neighbors. Two MNs attached to same link. Possible for MN to discover local hosts, then move. Is this acceptable? Issue 3: domain-wide address uniqueness Required on p2p links between MN_i, MAGS of domain When link changes, with DNA will conclude link did not change. Enforcement of domain-wide address uniqueness For global we are ok because using separate prefixes. Link-local: how to guarantee? Possible solution: p2p: configure same Link Local address on all MAGs shared: MAG defends other MAGs and MNs link local addresses on their behalf. Shared link support Shared link turned into p2p link Solves multicast RAs issue with per-MN prefix model Use of VLANs (disable bridging frames by 802.11 APs) Support for share link L2? Has issues 1. Multicast RA 2. discovery of neighbors 3. domain-wide address uniqueness Questions: Should we assume DNAv6? Do we want to support shared links? Vidya: before we go forward: we said we wouldn't support domain-wide shared links, but some people asked for shared last hop links. AlexPetrescu: it is a good question on whether we support shared links on last hop. I do support it. Discovery of neighbors on shared links while using simulated p2p link may have issues, but they are solvable. Vijay: on 1st question, not too comfortable requiring DNAv6. We need to make sure it works. Jari: on shared links: project management, if you are late, do you add new features? I think not. Adding complicated stuff like Proxy NDs doesn't seem like the way to go. Sri: so should we assume DNAv6? Jari: nothing about DNAv6, just talking about shared links. IPv6 has a certain behavior today, it would be really good if the WG can deliver a solution that works with that (for some value of works) Not sure whether you want to rely on DNAv6 or not, but if normal IPv6 addresses appear, should work. Vidya: seems like DNAv6 is needed with shared last hop. We don't have to require it mic: if there is a p2p link RA does not need to be unicast. To send RA in unicast, access router should manage the address of every node Sri: you get L2 unicast, L3 multicast mic: for unsolicited one, you have to send them periodically. Must send them in unicast. Have to detect every node attached to itself. We had this problem, some people were unsure whether router can be omniscient. Per-MN prefix: prefix is assigned not to an MN but to a link. In 3GPP and 16ng, we define a p2p link, then a prefix on that link. But here there is no mention of accompanying link. To which link are we assigning a prefix? Gerardo: DNAv6 and this draft: draft is targeted for informational. From discussion on the charter, we decided to include this as an example of how to define this interface but there should be no assumptions about how MN-AR interface is supported. We may say in this document, DNAv6 may have better performance, we need to be agnostic Julien: but do we want to support share links answer depends on whether we have DNAv6 Shumishelko: filter protocol will be proprietary? Shared links must be supported. Vidya: when you are saying must be supported, base protocol or leave for further study? Shumishelko: it may have a lot of impact on the base protocol. We may end up with 2 protocols, one for shared one for p2p. Vidya: we will extend the base protocol once we work out all the details of shared links. We are late wrt milestones. AlexP: shared links, remarking on comments from Gerardo: we shouldn't design specifically for proprietary system. Until now model we assume in proxy MIPv6 already has some assumptions on MN-AR. One assumption is that it uses this thing called a user profile, don't know how this arises. This is a strong assumption that is made. Vidya: need to address that, but it is not specific to IPv6 discussion we are having. Alex: per MN prefix, user profile, p2p links are assumptions made in PMIPv6 If we ignore shared link we ignore a whole class of solutions like campus deployments. Vidya: we are going to revisit shared links it just needs more work. Alex: don't need more work. 2 ways of addressing it: 1. add message formats more work, or 2. remove text that has assumptions. Such as: user profile. Sri: lot of comments on profile, it is configuration data. How does it know where to send the PBU? Alex: MN identifier, user profile. Sri: terms were requested by the chair Vidya: had some discussion on MN Identifier, if it's not needed for protocol operation then there is no requirement Kent: agree with what Jari said. It requires a lot more discussion and thought. From a process perspective, are we making a decision today, how will we resolve this? Vidya: we have been discussing for 6 months now, would like to make a decision quickly. There is general agreement with Jari's approach. Kent: so that's the decision? Vidya: right. Topic: IPv4 support (IPv4 MNs and IPv4 transport support) Presenter: Basavaraj Patil Time: 30 mins (Presentation: 5-10mins; Discussion: 20 mins) 2 drafts are entirely based on IPv6. There has been lengthy discussion on the mailing list. There is a need for IPv4 as well. Where is IPv4 support needed? 1. Mobile host itself (IPv4 only?) Protocol is primarily for IPv6 hosts. Could be Dual-Stack. 2. IPv4 between MAG and LMA for transport. 3. IPv4 support at LMA. Support for IPv4 hosts transport or IPv4 home address Protocol designed to support v6 and dual-stack hosts. Should NETLMM also support v4 only hosts? Seems outside of scope of current charter, but current proposals/discussions to support v4 as well. Implications: DS-LMA supporting IPv4 HoA NAT traversal mechanisms need to be in place Address assignment procedures in case of DHCP (v4/v6) Tunneling of the data traffic between the LMA and MAG will be IPv4 over IPv6. IPv4 support at the MAG Signaling in 2 drafts is based on MIPv6, transport network might be IPv4. Would be a limitation to assume IPv6. To ensure that this protocol can be deployed in current environment, need to support v4 transport network. MAG/LMA should be agnostic to the type of network. IPv4 support at LMA Support IPv4 HoA for v4 only hosts and for hosts that request a v4 address in addition to a v6 HoA. Single anchor point for connectivity to v4 and v6 networks Issues Is a host with a v4 & v6 address considered to be multi-homed? IPv4 address type Private vs Globally routable overlapping addresses in the same PMIP6 domain? Triggers for PMIP6: DHCPv4, DHCPv6? Applicability and use of v4/v6 transition mechanisms Reuse, criteria? There was a long discussion on the mailing list NAT Traversal solutions? Questions How important is it that the base spec includes v4 support? There seems to be general consensus that we need to support v4 addresses for MN, v4 transport network. More discussion around whether this belongs in the base or in extensions. PMIP6 is based on MIP6. Should DS-MIP6 be the basis for supporting IPv4 hosts, transition and NAT traversal? Use of DS-MIP6 DS-MIP6 is addressing these issues support for IPv4 network, v4 home addresse Hesham: I think it's obvious that we need to have v4 support having a NAT between AR and LMA is no issue. If we use DSMIP then NAT traversal comes for free. Raj: don't know, haven't looked at that issue where NAT between host and LMA? Hesham: in the PMIP scenario, NAT would be in that cloud. If we do have DS-MIP, if there's a NAT it still works. But don't know whether it is worth considering. Raj: no reason to expect NATs there, but solution needs to take into account that there may be NATs. Agree that DS-MIP gives us NAT traversal for free. Vidya: assumptions for v6 is per-MN prefix. For v4, does that assumption still make sense? Raj's assumption is that it is not per-MN prefix because of shortage of IP addresses Behcet: would draft-sgundave work if access network is v4 only? Raj: yes. Vijay: access network could be v4 or v6 GeorgeT: on question of whether we need v4, there should be v6 mobiles only. Isn't that obvious? Discussing NAT between MAG and LMA seems out of place. Tired of people thinking about NETLMM as a global mobility management scheme Sri: there could be NAT between LMA and MAG - this is a possible solution George; but why wouldn't LMA have a private address too? Raj: if you are already supporting v4 address, then mobility using v4 becomes redundant George: so do you believe MIP6 is redundant? Ajoy: find it hard to imagine why there would be a NAT. Even for case of SDOs, have not seen any scenarios where we need NAT between MAG and LMA. Raj: point noted about how important it is Marco: Issue list: what serves as trigger for proxy MIP operation. Can be DHCP or another mechanism. Question: IPv4: you are not questioning the control plane transport to be IPv4? Is it mandatory to have IPv6? If this is a question, don't understand it. There was another proposal that was agnostic, discussion led to IPv6. Vidya: assumption is still that MAG and LMA must support IPv6 for signaling. Question is that the network between them could be IPv4. Raj: signaling is basically IPv6 packets, cannot have any assumptions on the transport network that carries these. If the control plane protocol needs to be agnostic. Marco: if it is IPv4 only, then you cannot use netlmm Vijay: disagree whether we can make any assumptions. mic: from an operator perspective, would be better to have IPv4 support, including IPv4 on a UE. From SDOs: still continuing IPv4 connections so would like to see netlmm support both transports for signaling as well as UE's address Alex: 2 comments: 1. It is somehow true that we would like MAG & LMA to be dual stack. Then there are huge differences on whether this is an IPv6 or IPv4 based protocol. DS-MIPv6 implies MIPv6 signaling. MIPv4 has DS-MIPv4. 2. NAT: assuming or not assuming NAT between MAG and LMA: prefixes per MN: for IPv4, we can talk prefix per MN if we have a NAT. Without NAT, we can't talk prefix per MN because there are not enough of them. If we have prefix per MN for IPv6, why can't we do it with IPv4? Raj: could assign a /128 prefix as well. Vidya: triggers for IPv4 are different We will get to discussion later. Topic: MN ID requirements Presenter: TBD Time: 15 mins (Presentation: 5 mins; Discussion: 10 mins) Skipped due to lack of time. NEXT STEPS (5 minutes) Q: are we going to require per-MN prefixes for IPv4? Can the base draft support IPv4 or does it require more work? Behcet: has to be per-MN prefix Vijay: multilink subnet issues are not a problem because it is a p2p link between MN and LMA. Haven't seen an issue with per-MN IPv4 prefixes. Have to do private addresses it doesn't make any sense. Vidya: any comment from Jari? Jari: v4 stuff is outside the charter, but as I said on the list, if there are things you can do that don't take too much time (referencing DS-MIP) then that is fine. If it takes more than that might want to do it as a separate document. Have no problem re-chartering later. A little troubled by discussion on v4 per-mn prefix. Vidya: consensus call for document adoption ends on Friday. Those of you who have not responded please post comments to the list. MN-ID will be discussed on the list. One things we didn't get here today: didn't discuss whether we will support PMIPv6 and MIPv6 home domain in the same LMA. Need to discuss further on the list before we can say whether it makes sense to put it in the base document. Ajoy: consensus call is about draft-A vs. draft-B. Should we ask instead whether to combine 2 approaches? Jari: Consensus call: only picking the starting point for a -00 WG draft. Possibility/Requirement that WG pays attention and adds things that are needed. We are not assuming that we will adopt a perfect draft, we will build on it. Ajoy: so you are saying we will start with one and then add. Jari: yes, all the issues on the table still need to be addressed no matter what is chosen.