[addr-select-dt] resuming the discussion

Arifumi Matsumoto <arifumi@nttv6.net> Wed, 12 May 2010 08:58 UTC

Return-Path: <arifumi@nttv6.net>
X-Original-To: addr-select-dt@core3.amsl.com
Delivered-To: addr-select-dt@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5E543A6B13 for <addr-select-dt@core3.amsl.com>; Wed, 12 May 2010 01:58:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level:
X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_50=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qGhTlP67O29w for <addr-select-dt@core3.amsl.com>; Wed, 12 May 2010 01:58:26 -0700 (PDT)
Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id C56AA3A6B04 for <addr-select-dt@ietf.org>; Wed, 12 May 2010 01:58:20 -0700 (PDT)
Received: from [IPv6:2001:fa8:1000::8cd9:14af:262f:c104] ([IPv6:2001:fa8:1000:0:8cd9:14af:262f:c104]) by mail.nttv6.net (8.14.4/8.14.3) with ESMTP id o4C8w8J3081356 for <addr-select-dt@ietf.org>; Wed, 12 May 2010 17:58:09 +0900 (JST) (envelope-from arifumi@nttv6.net)
From: Arifumi Matsumoto <arifumi@nttv6.net>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 12 May 2010 17:58:08 +0900
Message-Id: <E5A6754A-E444-4D25-B8BF-1AF0C7917B0D@nttv6.net>
To: addr-select-dt@ietf.org
Mime-Version: 1.0 (Apple Message framework v1078)
X-Mailer: Apple Mail (2.1078)
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (mail.nttv6.net [IPv6:2001:fa8::25]); Wed, 12 May 2010 17:58:09 +0900 (JST)
Subject: [addr-select-dt] resuming the discussion
X-BeenThere: addr-select-dt@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IPv6 Address Selection Design Team <addr-select-dt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/addr-select-dt>, <mailto:addr-select-dt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/addr-select-dt>
List-Post: <mailto:addr-select-dt@ietf.org>
List-Help: <mailto:addr-select-dt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/addr-select-dt>, <mailto:addr-select-dt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 May 2010 08:58:27 -0000

Hi Design team members,

let me resume this mailing list, and start discussion towards next IETF.

At the IETF meeting in Anaheim, we got the following points.

- Aggressive mode and non-aggressive mode can move separately.
- XML based information distribution mechanism worth considering.
- Design Team needs more time to review the steps forward.
- 6man mailing list is next place to discuss after design team discussion.

So, in my understanding, after separating with aggressive mode way, we've reached consensus on that we need some mechanism to deliver something to end hosts.

Tony Hain gave me comments on mic telling that we should discuss WHAT we distribute.

So, maybe this is the next point we have to agree on.

Regarding the XML or DHCP, this is about HOW the information is distributed, so it may come after WHAT.

* The status of WHAT we distribute.

About this point, the utilization of RFC3484 policy table is proposed, as you know,
draft-fujisaki-dhc-addr-select-opt.

What else should we consider about this point.
Tony, can you elaborate on this point ?

* The status of HOW we distribute.

The following mechanisms are proposed/imagined.

- RA
- DHCP
- XML (HTTP ?)

I could not get what exactly "XML" means, but I guess it means SOAP/HTTP based configuration mechanism.

IMO, it is used to deliver additional further information to the end node, and not used for delivering basic IP configuration information. This is because, at least, the end node have to be able to reach the HTTP server to retrieve those information.
And, I think the address selection information is such a basic information that are used to reach off-link nodes.


Am I missing any other points to consider ?
Any comments are welcome.

-----
Just for reference.

http://www.ietf.org/proceedings/10mar/minutes/6man.txt

* Address Selection
     - Presenter : Arifumi Matsumoto
     - 4 drafts in progress
     - In solution space, investigating pros/cons of simultaneous connection approach.
     - Host tries all pairs of src/dst addresses in a short period.
          - Decreases timeouts.
          - Adds load to network.
     - Policy needed to prevent exposure of internal-use addresses.
     - Policy distribution via either normal or aggressive host/DHCP interaction
     - Aggressive stack leverages SHIM6 experience.
     Comment (Deng) - Most phones don't use DHCP, configuration comes via XML.
     Comment (Carpenter) - SHIM6 does not have much deployment experience.  Aggressive mode does reduce recovery time, but not as much as one would expect.
     Comment (Hain) - No reason to wait for the aggressive stack, more work is needed on it.  Is DHC the right place to follow-on?  Maybe XML is better.
     Comment (Haberman) - General working model is that DHC WG acts as reviewer/approver of DHCP work done in other WGs.  We should keep discussing this on the mailing list.
     Comment (Hain) - Design team needs one more pass of discussion on their list.
     Comemnt (Hinden) - Don't wait to move this discussion to the main list until the next meeting.


--
Arifumi Matsumoto
  Secure Communication Project
  NTT Information Sharing Platform Laboratories
  E-mail: arifumi@nttv6.net