Re: question regarding draft-ietf-6man-rfc3484-revise-02 section 2.3

Philip Homburg <pch-6man@u-1.phicoh.com> Wed, 30 March 2011 15:47 UTC

Return-Path: <pch-b6B5344D9@u-1.phicoh.com>
X-Original-To: ipv6@core3.amsl.com
Delivered-To: ipv6@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 091A53A6B71 for <ipv6@core3.amsl.com>; Wed, 30 Mar 2011 08:47:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.599
X-Spam-Level:
X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2]
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 Z0HRhYVZ2a-n for <ipv6@core3.amsl.com>; Wed, 30 Mar 2011 08:47:43 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by core3.amsl.com (Postfix) with ESMTP id AB2D13A6A48 for <ipv6@ietf.org>; Wed, 30 Mar 2011 08:47:41 -0700 (PDT)
Received: from stereo.hq.phicoh.net ([127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #2) id m1Q4xe2-0001VHC; Wed, 30 Mar 2011 17:49 +0200
Message-Id: <m1Q4xe2-0001VHC@stereo.hq.phicoh.net>
To: Arifumi Matsumoto <arifumi@nttv6.net>
Subject: Re: question regarding draft-ietf-6man-rfc3484-revise-02 section 2.3
From: Philip Homburg <pch-6man@u-1.phicoh.com>
Sender: pch-b6B5344D9@u-1.phicoh.com
References: <alpine.DEB.2.00.1103281015240.4842@uplift.swm.pp.se> <4D907D77.1030904@innovationslab.net> <alpine.DEB.2.00.1103281431180.4842@uplift.swm.pp.se> <A19FA9C8-ED0E-4F5F-A5D0-702653392B5E@nttv6.net>
In-reply-to: Your message of "Wed, 30 Mar 2011 00:15:03 +0900 ." <A19FA9C8-ED0E-4F5F-A5D0-702653392B5E@nttv6.net>
Date: Wed, 30 Mar 2011 17:49:05 +0200
Cc: ipv6@ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Mar 2011 15:47:44 -0000

In your letter dated Wed, 30 Mar 2011 00:15:03 +0900 you wrote:
>So, the description of this rule should be like:
>
>If the implementation can know and manage the coupling of a next-hop and a pre
>fix
>delegated from it, then the corresponding prefix should be chosen as the sourc
>e address.
>For example, in SLAAC case, ... (the description of how the coupling is acquir
>ed and used)

I think this is fine as an optimization, but do we really want to force hosts
to be involved in routing packets?

So far, the model is that a host can just dump a packet at a default router
and the router will figure it out.

In more complex setups, i.e. where there are multiple CPEs providing access
to different ISPs but also multiple internal LANs at the site, routers will
have to know the right exit for a packet anyhow.

So I would propose to focus on (and put emphasis on) getting routers to 
send packets to the right ISP and only add changes to the hosts as an
optimization.