From bridgetb@gmail.com Tue Sep 6 16:56:03 2011 Return-Path: X-Original-To: mip4@ietfa.amsl.com Delivered-To: mip4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A53E21F8F9F for ; Tue, 6 Sep 2011 16:56:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.391 X-Spam-Level: X-Spam-Status: No, score=-2.391 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iuYOilUcrazJ for ; Tue, 6 Sep 2011 16:56:02 -0700 (PDT) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id 362B321F8F9A for ; Tue, 6 Sep 2011 16:56:02 -0700 (PDT) Received: by pzk33 with SMTP id 33so17286168pzk.18 for ; Tue, 06 Sep 2011 16:57:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; bh=9xCgSeHhBpr6e18wT3Rmva0uteKgDQdE1+XnoylghGs=; b=BXfUoI4Qdw7G+uJ0CGHoT+8qHeMKqYetIrKvas1yoWfOJRlzvBZ2HVyPtFLKhdjC+m pGjefp890P4vBcmpEfOWcIzcDoeGagdk7pwZWns8cDE0hWjjApAhA3f3dOzIBCcMRHVu nLXgqmfXr5Q5JVyGRgg4jMX0idVpG6XCghMc4= Received: by 10.68.32.3 with SMTP id e3mr2088498pbi.13.1315353470065; Tue, 06 Sep 2011 16:57:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.191.4 with HTTP; Tue, 6 Sep 2011 16:57:30 -0700 (PDT) From: Bridget Benson Date: Tue, 6 Sep 2011 19:57:30 -0400 Message-ID: To: acf-members@autonomic-communication-forum.org, chi-announcements@acm.org, emstar-users@cens.ucla.edu, mip4@ietf.org, MOBICOM@acm.org, MOBICOM@listserv.acm.org, mobisys@acm.org Content-Type: multipart/alternative; boundary=bcaec51dd163565a9c04ac4e984f X-Mailman-Approved-At: Tue, 06 Sep 2011 18:27:45 -0700 Subject: [Mip4] ACM WUWNet'11: submission deadline postponed to Sep. 19 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Sep 2011 23:56:03 -0000 --bcaec51dd163565a9c04ac4e984f Content-Type: text/plain; charset=ISO-8859-1 [Apologies if you receive multiple copies.] Due to the severe aftermath of hurricane Irene, the paper submission deadline has been postponed to September 19, 2011. Note that this is a FIRM deadline. No further extensions will be granted. WUWNet'11: The Sixth ACM International Workshop on UnderWater Networks http://wuwnet.org/ December 1-2, 2011 Seattle, WA, USA CALL FOR PAPERS The oceans cover 71% of the Earth's surface and represent one of the least explored frontiers; yet, the oceans are integral to climate regulation, nutrient production, oil retrieval, and transportation. Also, water systems in general are of vital importance to life on Earth and commerce. For these reasons, there is significant interest in monitoring aquatic environments for scientific, environmental, commercial, safety, and military purposes. WUWNet is the premier venue for early work bringing real-time, in-situ sensing and actuation to this aquatic world. The goal of this workshop is to bring together researchers and practitioners in areas relevant to underwater networks. Thus, many layers of the communication stack - from the physical layer to the application layer - will be represented. The objective is to serve as a forum for presenting state-of-the-art research, for exchanging ideas and experiences, and for facilitating interaction and collaboration. The workshop will span two days, including presentations of technical papers, a keynote talk, a panel, and a poster/demo session. The scope of the WUWNet workshop covers a broad range of research directions related to underwater systems including communications, networking, system integration, and vehicle coordination. Specific topics of interest include, but are not limited to: - Underwater network architectures - Efficient underwater communications, with techniques from the physical layer to the application layer - Cooperative underwater communications, including, PHY, MAC, routing, and data transfer - Services for underwater systems, such as localization, time synchronization, reliable data transfer, security - Subsea communication for underwater vehicles (gliders, submersibles, etc.) - Coordination algorithms for underwater vehicles and sensor nodes, or human operator interaction - Modeling, simulation, and testbeds for underwater systems - Applications that broadly address subsea networks, including coordinated vehicle systems - Experimental results from underwater networking trials - Application requirements for underwater networks presented by end users SUBMISSION GUIDELINES Submissions for technical papers must describe original research, not published or currently under review for other workshops, conferences, journals, or magazines. All papers will be reviewed by the program committee for novelty and contribution. The workshop accepts two types of papers: full and short. Short papers may represent less mature work than full papers, or may contain new ideas for future research. Full papers should be more complete in their treatment of the topic. All accepted papers, full and short, will be published in the workshop proceedings. Paper submission will be handled electronically. Authors should prepare a PDF version of their papers. The page limit for full papers is 8 pages, and that for short papers is 5 pages in standard ACM conference format. Please see the workshop website for definitive formatting guidelines and sample templates. Furthermore, this year WUWNet will also have a Demo/Doctoral Symposium, which will provide a forum for both graduate and undergraduate students working on research topics relevant to WUWNet to discuss their goals, methods, and results at an early stage in their research. A 2-page extended abstract (in standard ACM conference format, with the student as first author) must be submitted by the deadline provided below. Last, but not least, a call for work-in-progress posters and demos will be announced separately. IMPORTANT DATES Paper registration: September 19, 2011 Paper submission: September 19, 2011 Acceptance notification: October 14, 2011 Camera-ready date: November 4, 2011 Workshop date: December 1-2, 2011 Demo/Doctoral Symposium extended abstract submission: September 30, 2011 Demo/Doctoral Symposium acceptance notification: October 14, 2011 Student travel grant submission: October 21, 2011 Student travel grant notification: October 28, 2011 ORGANIZERS General Chairs: Payman Arabshahi (Univ. of Washington) Jun-Hong Cui (Univ. of Connecticut) Program Committee Chairs: Qilian Liang (UT Arlington) Dario Pompili (Rutgers Univ.) Sumit Roy (Univ. of Washington) --bcaec51dd163565a9c04ac4e984f Content-Type: text/html; charset=ISO-8859-1 
[Apologies if you receive multiple copies.]


Due to the severe aftermath of hurricane Irene, the paper submission 
deadline has been postponed to September 19, 2011. Note that this is
a FIRM deadline. No further extensions will be granted. 


WUWNet'11: The Sixth ACM International Workshop on UnderWater Networks

http://wuwnet.org/

December 1-2, 2011

Seattle, WA, USA

CALL FOR PAPERS

The oceans cover 71% of the Earth's surface and represent one of the least
explored frontiers; yet, the oceans are integral to climate regulation,
nutrient production, oil retrieval, and transportation. Also, water systems
in general are of vital importance to life on Earth and commerce. For these
reasons, there is significant interest in monitoring aquatic environments
for scientific, environmental, commercial, safety, and military purposes.

WUWNet is the premier venue for early work bringing real-time, in-situ
sensing and actuation to this aquatic world. The goal of this workshop is to
bring together researchers and practitioners in areas relevant to underwater
networks. Thus, many layers of the communication stack - from the physical
layer to the application layer - will be represented. The objective is to
serve as a forum for presenting state-of-the-art research, for exchanging
ideas and experiences, and for facilitating interaction and collaboration.

The workshop will span two days, including presentations of technical
papers, a keynote talk, a panel, and a poster/demo session. The scope of the
WUWNet workshop covers a broad range of research directions related to
underwater systems including communications, networking, system integration,
and vehicle coordination. Specific topics of interest include, but are not
limited to:

-  Underwater network architectures
-  Efficient underwater communications, with techniques from the physical
layer to the application layer
-  Cooperative underwater communications, including, PHY, MAC, routing, and
data transfer
-  Services for underwater systems, such as localization, time
synchronization, reliable data transfer, security
-  Subsea communication for underwater vehicles (gliders, submersibles,
etc.)
-  Coordination algorithms for underwater vehicles and sensor nodes, or
human operator interaction
-  Modeling, simulation, and testbeds for underwater systems
-  Applications that broadly address subsea networks, including coordinated
vehicle systems
-  Experimental results from underwater networking trials
-  Application requirements for underwater networks presented by end users

SUBMISSION GUIDELINES

Submissions for technical papers must describe original research, not
published or currently under review for other workshops, conferences,
journals, or magazines.

All papers will be reviewed by the program committee for novelty and
contribution. The workshop accepts two types of papers: full and short.
Short papers may represent less mature work than full papers, or may contain
new ideas for future research. Full papers should be more complete in their
treatment of the topic. All accepted papers, full and short, will be
published in the workshop proceedings.

Paper submission will be handled electronically. Authors should prepare a
PDF version of their papers. The page limit for full papers is 8 pages, and
that for short papers is 5 pages in standard ACM conference format. Please
see the workshop website for definitive formatting guidelines and sample
templates.

Furthermore, this year WUWNet will also have a Demo/Doctoral
Symposium, which will provide a forum for both graduate and undergraduate
students working on research topics relevant to WUWNet to discuss their
goals, methods, and results at an early stage in their research. A 2-page
extended abstract (in standard ACM conference format, with the student as
first author) must be submitted by the deadline provided below.

Last, but not least, a call for work-in-progress posters and demos will be
announced separately.

IMPORTANT DATES

Paper registration:       September 19, 2011
Paper submission:         September 19, 2011
Acceptance notification:  October 14, 2011
Camera-ready date:        November 4, 2011
Workshop date:            December 1-2, 2011

Demo/Doctoral Symposium extended abstract submission:    September 30, 2011
Demo/Doctoral Symposium acceptance notification:        October 14, 2011
Student travel grant submission:                    October 21, 2011
Student travel grant notification:                    October 28, 2011

ORGANIZERS

General Chairs:
Payman Arabshahi (Univ. of Washington)
Jun-Hong Cui (Univ. of Connecticut)

Program Committee Chairs:
Qilian Liang (UT Arlington)
Dario Pompili (Rutgers Univ.)
Sumit Roy (Univ. of Washington)
--bcaec51dd163565a9c04ac4e984f-- From jari.arkko@piuha.net Thu Sep 15 14:29:04 2011 Return-Path: X-Original-To: mip4@ietfa.amsl.com Delivered-To: mip4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9842811E809A for ; Thu, 15 Sep 2011 14:29:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id THJkgXLElvXw for ; Thu, 15 Sep 2011 14:29:04 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 9A0FC11E807F for ; Thu, 15 Sep 2011 14:29:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 0643E2CEFF; Fri, 16 Sep 2011 00:31:16 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GJDNxqXTIJ0P; Fri, 16 Sep 2011 00:31:14 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id DFC842CE32; Fri, 16 Sep 2011 00:31:14 +0300 (EEST) Message-ID: <4E726EA2.7020409@piuha.net> Date: Fri, 16 Sep 2011 00:31:14 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Thunderbird/3.1.13 MIME-Version: 1.0 To: draft-ietf-mip4-nemo-haaro@tools.ietf.org, Mobile IPv4 Mailing List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Mip4] AD review of draft-ietf-mip4-nemo-haaro (part 1) X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2011 21:29:04 -0000 I am reviewing this draft. So far I have progressed to the end of Section 3.3.3, and I have no major complaints. A couple of comments, however: Section 1 should highlight that any route optimization between the MRs would only affect traffic between them. That is, traffic to somewhere else in the Internet in the multihoming case of figure 1 would still go through the virtual home agent operator, not directly. Section 3.3.1 should highlight that if there is only one realm that can be communicated with one prefix, this may not be sufficient to communicate many real-world situations (such as one prefix mapping to multiple organizations, e.g., nomadiclab.com and ericsson.com) The document should make it clear what types of NATs it can operate with. (And maybe it already does, in some part that I have not yet read :-) > If the check passes, the Correspondent Router MUST check whether the > Mobile Router already exists in its Route Optimization Cache and is > associated with the prefixes included in the request (Prefixes are > present and Flag HA is true for each prefix). > Can you make it clearer that checking whether an MR exists in the cache means checking whether an MR with the given care-of address exists in the cache? (If you didn't check the care-of address, any authorized router could claim any authorized prefix.) Jari From jari.arkko@piuha.net Fri Sep 16 04:22:19 2011 Return-Path: X-Original-To: mip4@ietfa.amsl.com Delivered-To: mip4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93C3321F8B03 for ; Fri, 16 Sep 2011 04:22:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gSNd7es47vlt for ; Fri, 16 Sep 2011 04:22:19 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id B66D321F8AD9 for ; Fri, 16 Sep 2011 04:22:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 2DA872D543; Fri, 16 Sep 2011 14:24:32 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nDSIg9F5dVGK; Fri, 16 Sep 2011 14:24:31 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 4E5D62CE32; Fri, 16 Sep 2011 14:24:31 +0300 (EEST) Message-ID: <4E7331EF.1020400@piuha.net> Date: Fri, 16 Sep 2011 14:24:31 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Thunderbird/3.1.13 MIME-Version: 1.0 To: draft-ietf-mip4-nemo-haaro@tools.ietf.org, Mobile IPv4 Mailing List References: <4E726EA2.7020409@piuha.net> In-Reply-To: <4E726EA2.7020409@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Mip4] AD review of draft-ietf-mip4-nemo-haaro (part 2) X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2011 11:22:19 -0000 Continuing my review. I think the document is in pretty good shape, but there were a few issues that I would like you to resolve before moving forward. The biggest issues are that I think you could do a better job in the introduction describing what kind of NAT scenarios this technology can work with, and adding a description of areas of uncertainty/problems that would be worthwhile to get more experience on (since the doc is going to be published as Experimental RFC). > When a Mobile Router wishes to join its home link, it SHOULD, in > addition to sending the registration request to the Home Agent with > lifetime set to zero, also send such a request to all known > Correspondent Routers. I think it would be useful to clarify that you send the request to the home address, not care-of address of the CRs. Right? Otherwise they may have moved. > In the case of a handover, the Correspondent Router simply needs to > update the tunnel's destination to the Mobile Router's new Care-of > Address. Mobile Router SHOULD keep accepting packets from both old > and new care-of Addresses for a short grace period, typically on the > order of ten seconds. In the case of UDP encapsulation, the port > numbers SHOULD be reused if possible. > Its not as simple as that when NATs and firewalls are involved. If the MR is behind a NAT now, it needs to send a packet first. But will it send a packet to the care-of address or home address of the CR or both? If care-of address, the CR may just have moved. If home address, there will be no pinhole opened in the NAT. RR may open the pinholes (but is it running on top of the same UDP ports as tunnels? I'm not sure.) > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Sub-type | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > 1..n times the following information structure > It was unclear to me what the relationship of "n" and "Length" are. Please clarify. > In > the case of one or both of the routers is known to be behind NAT or > similarly impaired (not being able to accept incoming connections), > the tunnel establishment procedure SHOULD take this into account. This is not an implementable requirement. What follows after this text is better, and that's the beef of what implementations must actually do. I would change the above text with s/SHOULD/need to/. Since this specification is experimental, your Section 1 should describe the areas which are uncertain and which would benefit from experience with implementations and deployment. For instance, Section 7 lists scalability to a large number of prefixes as an area where further experience is needed. Section 3.3 an 8.3 seem to disagree. The former says Krm is invalidated if care-of address changes, yet the 8.3 example does not appear to rerun RR (or the care-of address test part of RR). Jari From mccap@petoni.org Mon Sep 26 08:46:23 2011 Return-Path: X-Original-To: mip4@ietfa.amsl.com Delivered-To: mip4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C76811E809A for ; Mon, 26 Sep 2011 08:46:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LXh5erWBqPQi for ; Mon, 26 Sep 2011 08:46:22 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 51E6F11E8089 for ; Mon, 26 Sep 2011 08:46:22 -0700 (PDT) Received: by gwj15 with SMTP id 15so5650301gwj.31 for ; Mon, 26 Sep 2011 08:49:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=petoni.org; s=google; h=mime-version:x-originating-ip:date:message-id:subject:from:to :content-type; bh=Qji+JTRn3ahTAiI9e9XMGw9+ULx9m3h6v9BorCJ2Ym4=; b=Ql70alHzJ42g/bqSBt0GhqZ00O4hW2kWnunXoYNEwzFmdWixst2REvKdEjknelzxQj DTG/ndi3FdbTTRZv8k/BRxo0zAsEKk2TkNZibiCjVPwDbTp1JimEkfTSr84y7El2r/Uu OU8/+WrtyB5qT27S6h5hxc5j9BfObLnHbZ5EA= MIME-Version: 1.0 Received: by 10.150.169.11 with SMTP id r11mr6061779ybe.315.1317052144991; Mon, 26 Sep 2011 08:49:04 -0700 (PDT) Received: by 10.151.147.11 with HTTP; Mon, 26 Sep 2011 08:49:04 -0700 (PDT) X-Originating-IP: [4.28.5.163] Date: Mon, 26 Sep 2011 11:49:04 -0400 Message-ID: From: Pete McCann To: mip4@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [Mip4] WG Last Call: draft-ietf-mip4-multiple-tunnel-support-02 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2011 15:46:23 -0000 This message announces a WG last call on: "Flow Binding Support for Mobile IPv4" draft-ietf-mip4-multiple-tunnel-support-02 This draft is intended for publication as an Experimental RFC. The last call will conclude at 24:00 UTC on Monday October 10, 2011. This specification defines extensions to Mobile IPv4 protocol for allowing a mobile node with multiple interfaces to register a care-of address for each of its network interfaces and to simultaneously establish multiple Mobile IP tunnels with its home agent. This essentially allows the mobile node to utilize all the available network interfaces and build an higher aggregated data pipe with the home agent for its home address traffic. Furthermore, these extensions also allow the mobile node and the home agent to negotiate flow policies for binding individual traffic flows with the registered care-of addresses. A URL for this Internet-Draft is: Please respond to this WG last call: * If you have no comments on the draft, and support its advancement, simply respond with a line containing something like: "I support the advancement of this document to the IESG with a request for publication as an Experimental RFC." If you have comments, please use a line similar to the one above, and supplement this with your comments. * If you *don't* support its advancement, respond with a line containing something like the following, supplemented by your comments: "I don't support the advancement of this document to the IESG with a request for publication as Experimental RFC, for the following reasons:" ... -Pete From antti.makela@aalto.fi Fri Sep 30 04:47:47 2011 Return-Path: X-Original-To: mip4@ietfa.amsl.com Delivered-To: mip4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43ECB21F8B20 for ; Fri, 30 Sep 2011 04:47:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pzbfsxr-7rTc for ; Fri, 30 Sep 2011 04:47:46 -0700 (PDT) Received: from mx05.aalto.fi (mx05.aalto.fi [130.233.222.104]) by ietfa.amsl.com (Postfix) with ESMTP id DE77C21F8B09 for ; Fri, 30 Sep 2011 04:47:45 -0700 (PDT) Received: from mx05.aalto.fi (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id AE4B080D4A; Fri, 30 Sep 2011 14:50:38 +0300 (EEST) Received: from EXHUB04.org.aalto.fi (ex-hub04.org.aalto.fi [130.233.222.117]) by mx05.aalto.fi (Postfix) with ESMTP id 97EE080D48; Fri, 30 Sep 2011 14:50:38 +0300 (EEST) Received: from EXMDB08.org.aalto.fi ([169.254.8.66]) by EXHUB04.org.aalto.fi ([130.233.222.117]) with mapi id 14.01.0270.001; Fri, 30 Sep 2011 14:50:38 +0300 From: =?iso-8859-1?Q?M=E4kel=E4_Antti?= To: Jari Arkko , "draft-ietf-mip4-nemo-haaro@tools.ietf.org" , Mobile IPv4 Mailing List Thread-Topic: [Mip4] AD review of draft-ietf-mip4-nemo-haaro Thread-Index: AQHMf2QwNHqQCgjt8kOYStncztQ+DA== Date: Fri, 30 Sep 2011 11:50:38 +0000 Message-ID: <64FACAB831EEEB418F27A18FE09095244E933E34@EXMDB08.org.aalto.fi> Accept-Language: en-US, fi-FI Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [84.249.138.135] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Mip4] AD review of draft-ietf-mip4-nemo-haaro X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2011 11:47:47 -0000 Hi,=0A= =0A= Consolidating both of your review e-mails into one. Comments inline. Over= all we'll need more information in section 1 and some clarifications. We'll= try to submit -06 soon.=0A= =0A= >Section 1 should highlight that any route optimization between the MRs wou= ld only affect traffic between >them. That is, traffic to somewhere else in= the Internet in the multihoming case of figure 1 would still go >through t= he virtual home agent operator, not directly.=0A= =0A= Actually, technically you could have a separate "MR" that would act as an= Internet gateway, by advertising prefix 0.0.0.0/0. So HA would truly be re= legated as nothing but a signaling anchor. But we'll add text to indicate t= his.=0A= =0A= >Section 3.3.1 should highlight that if there is only one realm that can be= communicated with one prefix, >this may not be sufficient to communicate m= any real-world situations (such as one prefix mapping to >multiple organiza= tions, e.g., nomadiclab.com and ericsson.com)=0A= =0A= Our original approach was worrying about the situation where there's over= lapping (private) address spaces, since that ericsson.com's 10.10.10.0/24 i= s not same beast as cisco.com's 10.10.10.0/24, so in fact you could send th= e same prefix out twice with different realms, and then it would be up to t= he policies set for the MR whether whether they allow connectivity between = such two entities (and how do they do it - some sort of NAT would probably = be needed). In same vein, such a policy could be set up that in case of nom= adiclab and ericcson the prefix is in fact the same network.. =0A= =0A= We'll add these considerations as well.=0A= =0A= >The document should make it clear what types of NATs it can operate with. = (And maybe it already does, >in some part that I have not yet read :-)=0A= =0A= This is covered later.=0A= =0A= >> If the check passes, the Correspondent Router MUST check whether the= =0A= >> Mobile Router already exists in its Route Optimization Cache and is= =0A= >> associated with the prefixes included in the request (Prefixes are= =0A= >> present and Flag HA is true for each prefix).=0A= >Can you make it clearer that checking whether an MR exists in the cache me= ans checking whether an >MR with the given care-of address exists in the ca= che? (If you didn't check the care-of address, any >authorized router could= claim any authorized prefix.)=0A= =0A= Ok.=0A= =0A= >I think the document is in pretty good shape, but there were a few issues = that I would like you to resolve >before moving forward. The biggest issues= are that I think you could do a better job in the introduction >describing= what kind of NAT scenarios this technology can work with, and adding a des= cription of areas >of uncertainty/problems that would be worthwhile to get = more experience on (since the doc is going to be >published as Experimental= RFC).=0A= =0A= Ok - will add. We have already done some research on e.g. how to combine t= his with Sri's multiple tunnel support draft and load balancing issues (sub= mission pending acceptance to a journal). Should such academic papers be ci= ted as informational references?=0A= =0A= >> When a Mobile Router wishes to join its home link, it SHOULD, in=0A= >> addition to sending the registration request to the Home Agent with=0A= >> lifetime set to zero, also send such a request to all known=0A= >> Correspondent Routers.=0A= >I think it would be useful to clarify that you send the request to the hom= e address, not care-of address of >the CRs. Right? Otherwise they may have = moved.=0A= =0A= Ok. Of course, all the signaling between MRs happens by using their Home = Address, but can repeat that point here.=0A= =0A= >> In the case of a handover, the Correspondent Router simply needs to= =0A= >> update the tunnel's destination to the Mobile Router's new Care-of= =0A= >> Address. Mobile Router SHOULD keep accepting packets from both old= =0A= >> and new care-of Addresses for a short grace period, typically on the= =0A= >> order of ten seconds. In the case of UDP encapsulation, the port=0A= >> numbers SHOULD be reused if possible.=0A= >Its not as simple as that when NATs and firewalls are involved. If the MR = is behind a NAT now, it needs >to send a packet first. But will it send a p= acket to the care-of address or home address of the CR or both? >If care-of= address, the CR may just have moved. If home address, there will be no pin= hole opened in the >NAT.=0A= >=0A= >RR may open the pinholes (but is it running on top of the same UDP ports a= s tunnels? I'm not sure.)=0A= =0A= It is. However, the pinhole (and checking of it's validity!) is actually = created by the first keepalive message.=0A= =0A= Basically, what happens is:=0A= =0A= MR behind NAT #1, CR sees MR with NAT #1's external addr=0A= MR moves to NAT #2, remains connected via NAT #1, re-registers to HA=0A= MR sends (RR and) registration request to CR (to CR's home address)=0A= CR sees MR's registration coming from the NAT #2's external addr, replies= =0A= MR sends first keepalive to CR (directly), CR replies, now sees the UDP p= ort used for actual end-user data. (This is covered in 6.1, 4th paragraph) = - the registration signaling was conducted between MR's CoA to CR's HoA.=0A= =3D> Tunnel open via the new path=0A= =0A= Now, if both MR and CR are behind (separate) NATs, then that's of course = a whole different story, but this scenario is covered in 6.1 as "out-of-sco= pe". =0A= =0A= However, apparently this could also use some clarification...=0A= =0A= =0A= >> 0 1 2 3=0A= >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=0A= >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= =0A= >> | Type | Sub-type | Length |= =0A= >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= =0A= >> 1..n times the following information structure=0A= >It was unclear to me what the relationship of "n" and "Length" are. Please= clarify.=0A= =0A= The relationship is that "when you have read the information structure, i= f you have already reached Length octets, you have also reached n"...Will c= larify.=0A= =0A= >> In=0A= >> the case of one or both of the routers is known to be behind NAT or= =0A= >> similarly impaired (not being able to accept incoming connections),= =0A= >> the tunnel establishment procedure SHOULD take this into account.=0A= >=0A= >This is not an implementable requirement. What follows after this text is = better, and that's the beef of what >implementations must actually do. I wo= uld change the above text with s/SHOULD/need to/.=0A= =0A= Ok.=0A= =0A= >Since this specification is experimental, your Section 1 should describe t= he areas which are uncertain and >which would benefit from experience with = implementations and deployment. For instance, Section 7 lists >scalability = to a large number of prefixes as an area where further experience is needed= .=0A= =0A= Ok.=0A= =0A= >Section 3.3 an 8.3 seem to disagree. The former says Krm is invalidated if= care-of address changes, yet >the 8.3 example does not appear to rerun RR = (or the care-of address test part of RR).=0A= =0A= The diagram in 8.3 omits RR since it can be optional (with e.g. static ke= ys). Will add that.=0A= =0A= Thanks.=0A= =0A= --=0A= - Antti M=E4kel=E4 | Researcher -=0A= - Department of communications and networking -=0A= - Aalto University -=0A= From jari.arkko@piuha.net Fri Sep 30 05:00:04 2011 Return-Path: X-Original-To: mip4@ietfa.amsl.com Delivered-To: mip4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD47621F8696 for ; Fri, 30 Sep 2011 05:00:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.227 X-Spam-Level: X-Spam-Status: No, score=-102.227 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CMIVvpgH-I3X for ; Fri, 30 Sep 2011 05:00:04 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 2D5B421F84D7 for ; Fri, 30 Sep 2011 05:00:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 87BE92CEFF; Fri, 30 Sep 2011 15:02:57 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VIhUTtyeYEo0; Fri, 30 Sep 2011 15:02:56 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 5BA9E2CE32; Fri, 30 Sep 2011 15:02:56 +0300 (EEST) Message-ID: <4E85AFEF.6040901@piuha.net> Date: Fri, 30 Sep 2011 15:02:55 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 MIME-Version: 1.0 To: =?ISO-8859-1?Q?M=E4kel=E4_Antti?= References: <64FACAB831EEEB418F27A18FE09095244E933E34@EXMDB08.org.aalto.fi> In-Reply-To: <64FACAB831EEEB418F27A18FE09095244E933E34@EXMDB08.org.aalto.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "draft-ietf-mip4-nemo-haaro@tools.ietf.org" , Mobile IPv4 Mailing List Subject: Re: [Mip4] AD review of draft-ietf-mip4-nemo-haaro X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2011 12:00:04 -0000 Thanks for your response. The responses made sense to me. I'll wait for a new draft version... Jari