Re: question about draft-ietf-6man-rfc3484bis-06.txt and CommonPrefixLen()

Karl Auer <kauer@biplane.com.au> Tue, 31 July 2012 00:08 UTC

Return-Path: <kauer@biplane.com.au>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E5AF11E80CC for <ipv6@ietfa.amsl.com>; Mon, 30 Jul 2012 17:08:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, J_CHICKENPOX_21=0.6]
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 tWAKHtjD3rCK for <ipv6@ietfa.amsl.com>; Mon, 30 Jul 2012 17:08:42 -0700 (PDT)
Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:7]) by ietfa.amsl.com (Postfix) with ESMTP id 5925511E8099 for <ipv6@ietf.org>; Mon, 30 Jul 2012 17:08:40 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApMBAJAgF1CWZX+7/2dsb2JhbAANOIVztw0BAQEEDhVCJAsYAgImAgJXGa9AbpMdgSGBIYx7ggqBEgOgVodx
Received: from eth4284.nsw.adsl.internode.on.net (HELO [192.168.1.200]) ([150.101.127.187]) by ipmail07.adl2.internode.on.net with ESMTP; 31 Jul 2012 09:38:37 +0930
Subject: Re: question about draft-ietf-6man-rfc3484bis-06.txt and CommonPrefixLen()
From: Karl Auer <kauer@biplane.com.au>
To: ipv6@ietf.org
In-Reply-To: <CABTuw1A=YiwaBYMD1rfEV6QnK=nqTW2+wbFsEES9JPP7WOt0+A@mail.gmail.com>
References: <1343085852.2796.201.camel@karl> <1343524489.3497.94.camel@karl> <CABTuw1A=YiwaBYMD1rfEV6QnK=nqTW2+wbFsEES9JPP7WOt0+A@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Date: Tue, 31 Jul 2012 10:08:15 +1000
Message-ID: <1343693295.26898.53.camel@karl>
Mime-Version: 1.0
X-Mailer: Evolution 2.30.3
Content-Transfer-Encoding: 7bit
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Tue, 31 Jul 2012 00:08:43 -0000

On Tue, 2012-07-31 at 08:30 +0900, Arifumi Matsumoto wrote:
> In my understanding, there is no use to look at the interface id part
> also for source address selection as well as for destination address
> selection.
> 
> DNS load balance issue is explicitly specified, because it is clear
> problem that we see.

Thanks, Arifumi, but I don't understand your point. You have not said
*why* "there is no use".

I do see the rationale for stopping the comparison at the prefix length
for *destination* address selection. I do not see the rationale for
doing so for *source* address selection.

Perhaps we need to distinguish between source address selection and
source address checking. I just made up that second term :-)

Source address selection is the process of choosing which source address
will be used in an outgoing packet.

Source address checking is the process, performed during destination
address selection, of looking to see which source address *would* be
selected if a given destination address were selected.

My question is about the first of these two, not the second. I don't see
how DNS load balancing affects the first.

Regards, K.

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer (kauer@biplane.com.au)
http://www.biplane.com.au/kauer
http://www.biplane.com.au/blog

GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017
Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687