#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ # NEMO WG WEDNESDAY, 22 MARCH 2006, 15:10 - 16:10 # 65th IETF Meeting Dallas # IETF 20th Anniversary # http://www.ietf.org/html.charters/nemo-charter.html # WG Chairs: Thierry Ernst , TJ Kniveton # # MINUTES # # All NEMO WG related documents and meeting material available on # http://www.mobilenetworks.org/nemo/ # #~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1 Welcoming, Agenda Bashing, WG doc status ...................................... 05mins Chairs 2. WG Documents Status & Last Calls ............................................... 05mins TJ Kniveton - NEMO Terminology - A few lingering questions. Thierry will send an e-mail to the list regarding the definition of Split NEMO, and Network Models terms definitions are being discussed on e-mail. - NEMO Requirements - no changes, but will be submitted w/ Terminology - Home Network Models draft is in approved state, and progressing through IESG 3 Analysis of Multihoming in Network Mobility Support ............................ 10mins ChanWah Ng http://www.ietf.org/internet-drafts/draft-ietf-nemo-multihoming-issues-05.txt Issue List: http://www.mobilenetworks.org/nemo/draft-ietf-nemo-multihoming-issues/ - Only one new issue, #23, involving description of ingress filtering, based on last IETF meeting - Instead of recommending issues to be solved in certain working groups, we state that they should be solved elsewhere in the IETF - Not issuing working group last call until some minor modifications are completed - See draft for list of recommendations for what NEMO should work on 4 NEMO Routing Optimization Masafumi Watari - These were mostly done as of the last meeting, but there were some small changes that I'll go over 4a Status of the NEMO RO Problem Statement draft .................................. 05mins http://www.ietf.org/internet-drafts/draft-ietf-nemo-ro-problem-statement-02.txt - Added text to Appendix added by Alex to clarify what the stalemate problem is - Editorial: Clarified abstract and the document in general - WG Last Call on Feb 16, completed - no additional comments were received 4b NEMO RO Solution Space Analysis draft .......................................... 05mins http://www.ietf.org/internet-drafts/draft-ietf-nemo-ro-space-analysis-02.txt - Some editorial issues raised by Thierry - Waiting for his response to changes that were made - About 21 issues were all closed and changes made - Also had WG last call on Feb 16 with no additional comments 5 NEMO v4 and NEMO v6 5a NEMO Basic Support and IPv4 .................................................... 05mins Alexandru Petrescu http://www.ietf.org/internet-drafts/draft-ietf-nemo-v4-base-00.txt - Protocol overview - based on RFC 3344 (MIPv4) and RFC 3963 (NEMO) - Changes since last meeting - Registration Request - With Mobile Network Prefix - Reply - With Mobile Network Prefix and status of registration - This was presented in Vancouver. We received suggestions from Binding ID draft to integrated Binding ID for MIPv4. Also to keep multihoming, multipath extensions separate from base spec as with MIPv6. Vijay D.: What is the status of this document - info, experimental, proposed? TJ: At the last IETF, we concluded this would be informational. Kent L.: What's the action item for this draft? What needs to be done? TJ: Unless there are any comments, this is considered WG last call (since it's Informational). So we can put it forward to the IESG after this meeting. 5b Status of the Mip6trans DT ..................................................... 05mins Hesham Soliman http://www.ietf.org/internet-drafts/draft-ietf-mip6-nemo-v4traversal-01.txt - Joint design team between NEMO and MIPv6 (presentation was also given in MIP6 WG) - First update of the draft. Objective of the draft is to remove dependency between MIP version and IP address version. IPv4-v6 addresses can be bound regardless of the MIP version being used - Also NAT detection and traversal support - A number of issues raised and handled - Proxy ARP for v4 home address - Editorial changes - BU / BAck symmetrical; always sent in UDP - New feature for forcing UDP encapsulation regardless of NAT detection - Use of mapped addresses and security- these two issues have recently been raised and will go in next revision of the draft - Please look at the draft and make sure it's clear from a NEMO implementor's point of view. Not too many comments have been received 6 Prefix Delegation .............................................................. 10mins Ralph Droms http://www.ietf.org/internet-drafts/draft-ietf-nemo-dhcpv6-pd-01.txt - Based on feedback, made some modifications to the draft and resubmitted - Assumes there is a DHCP service in the home network to do prefix delegation, that the MR will act as a DHCPv6 agent, and uses delegation unchanged from RFC 3633. Message go through tunnel from MR to HA just like other applications Francis Dupont: You assume the tunnel between MR and HA is an interface (with link-local addresses)? Ralph: Yes. - Relay agents: 3633 does not define the use of prefix delegation through relay agents. There must be a way for the relay agent to insert a route to the requesting router from the first upstream device. Francis: It doesn't say you can't do this either. There is now a solution with notify from the DHCP server. MR should be a relay. It would be easier. Ralph: I have to think about that a little bit. HA could also be a relay. Erik: But then you have to do host routes; you can't do prefix routes. The relay agent needs to put a subnet prefix in the request, or else how does the server know what pool to grab new addresses from? Sri G.: Can't that policy at the MR, as to which prefix to delegate from? Vijay D.: The relay agent has to be on the HA, not the MR. It tells the DHCP server which subnet prefix to delegate from. Ralph: The MR could use a routing protocol, it could be in a BU, or the server could notify the HA about the address just allocated so it can define a route. The third option is being developed in the DHCP working group - Description of how DHCPv6 works, and getting away from snooping on packets. Anticipating authenticated DHCP. So DHCPv6 uses full encapsulation so message from client is in an envelope from relay agent, with possible extra options added. Hesham: HA needs to know MR is authorized to use a particular prefix. Ralph: True, and MSOs don't want to trust CPE routers. (Comment from Francis) Vijay: In NEMO, we treat link between MR and HA is IP-IP tunnel. It is called a tunnel interface, but Francis is pointing out that the DHCP specs are strict to say that they should operate on one link. This needs to be relaxed to say that a 1-hop tunnel will be OK too. Ralph: So that client can transmit to relay agent using link-local addresses. Kent: This information can be contained in the BU as well. We get prefixes from DHCP server; it has to be mapped to what the server should be allocating, and it can be done dynamically. Hesham: BU will have to be sent after prefix, but even then it's not authorized. After DHCP exchange, it would look like you have a static prefix. - Not ready for working group last call. First we have to: - Make route injection text informative, not normative - Solve identifier problem that Hesham brought up Vijay: What happened to other prefix delegation draft? TJ: Hasn't been updated; we might merge this with DHCPv6 draft - have to speak with Ralph and Pascal 7 NEMO WG Status and Charter ..................................................... 05mins TJ Kniveton - Went over current milestones and status according to present charter - New proposed charter to be posted after this meeting. (Discussion followed on NEMO mailing list) - Went through new proposed charter and changes - Milestones to complete WG documents that are already in progress - Working on route optimization and multihoming by solving problems specific to NEMO deployment Masafumi W.: What do you mean by continuing to work on route optimization? TJ: We've been looking at problem space, and now we want to address specific deployment-important scenarios. James: "Security considerations will also be considered" - can you elaborate on that? TJ: This is meant to imply that we will address security for solutions that are proposed. It is not specifically a separate work item. Vijay: Route Optimization should be split up - analysis, scenarios, solution documents. For multihoming, I thought it was Monami6 TJ: Document we have lists suggestions - most things will be handled in other WGs. But the (n,n,n) ingress filtering was recommended to be solved by us in Chan-Wah's presentation. Alex: NEMOv4 is missing TJ: Yes, I'll add that. Masafumi W.: Can analysis and problem statement drafts be processed now instead of July? 8 Conclusion / Wrap Up ........................................................... 05mins TJ Kniveton - I won't be at the next meeting in Montreal, but hopefully Thierry will be there. - Thanks