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

Arifumi Matsumoto <arifumi@nttv6.net> Mon, 30 July 2012 23:30 UTC

Return-Path: <n@arifumi.net>
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 47D2B11E8138 for <ipv6@ietfa.amsl.com>; Mon, 30 Jul 2012 16:30:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.377
X-Spam-Level:
X-Spam-Status: No, score=-102.377 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1, 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 Pq7exsJ2b0Zm for <ipv6@ietfa.amsl.com>; Mon, 30 Jul 2012 16:30:18 -0700 (PDT)
Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 04D7311E8109 for <ipv6@ietf.org>; Mon, 30 Jul 2012 16:30:17 -0700 (PDT)
Received: by vcbfo14 with SMTP id fo14so5502149vcb.31 for <ipv6@ietf.org>; Mon, 30 Jul 2012 16:30:17 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=8iF0XIsKKCdIXGN0xuFLMCnDIsCXL9EowqIUSFBXvXk=; b=PnfVOE9p0DOYkkTX7Y+6Mt0hgbDav+NO5yPPm9eAG8uMgFrTWC1XoYUljPPGdkKrDg W2m/0BaXUAEJD3P7HPaqPYVbLO2XSWLvGeBRHSUBhWNuOhnYp8v9xoY+5QMJnDJlZCQV TwchyavV+zMg470ZpCN7Di8Mpy/CPhdP/JGf7BzirxSTC5x1biZz+JqoJCcMqJ1sC2e5 bHc0cAm83bZpfgbAJKQI3nGwmRGHc6RTHaDFhe2azvpNPK0IlSkbItxAANSDOsBw2DSn tFw17X020H55L2CT18hcrU5mh6cYRiLS7vyt/FLlFPVhTAhCrnUGZlVSh1ytXiH/VRV0 5xOA==
MIME-Version: 1.0
Received: by 10.221.1.137 with SMTP id nq9mr12510667vcb.16.1343691017240; Mon, 30 Jul 2012 16:30:17 -0700 (PDT)
Sender: n@arifumi.net
Received: by 10.58.94.132 with HTTP; Mon, 30 Jul 2012 16:30:17 -0700 (PDT)
X-Originating-IP: [130.129.16.149]
In-Reply-To: <1343524489.3497.94.camel@karl>
References: <1343085852.2796.201.camel@karl> <1343524489.3497.94.camel@karl>
Date: Tue, 31 Jul 2012 08:30:17 +0900
X-Google-Sender-Auth: 4BxU1Rm-zjS221vj7J2kV6LxK3M
Message-ID: <CABTuw1A=YiwaBYMD1rfEV6QnK=nqTW2+wbFsEES9JPP7WOt0+A@mail.gmail.com>
Subject: Re: question about draft-ietf-6man-rfc3484bis-06.txt and CommonPrefixLen()
From: Arifumi Matsumoto <arifumi@nttv6.net>
To: Karl Auer <kauer@biplane.com.au>
Content-Type: text/plain; charset=ISO-8859-1
X-Gm-Message-State: ALoCoQm7OYRaszEDOoMU1C9bNSiFiZwuaV6VmEhvdtJV3oI1EVHvHejZRJDG/Jf0qLRZtGNt1Ofr
Cc: ipv6@ietf.org
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: Mon, 30 Jul 2012 23:30:19 -0000

Karl,

2012/7/29 Karl Auer <kauer@biplane.com.au>au>:
> A few days ago, I asked about this draft as below. I haven't seen a
> response, but the question still seems fair.
>
>> I don't fully understand this change (from section Appendix B):
>>
>> 1.  Changed the definition of CommonPrefixLen() to only compare bits
>>        up to the source address's prefix length.  The previous
>>        definition used the entire source address, rather than only its
>>        prefix. As a result, when a source and destination addresses
>>        had the same prefix, common bits in the interface ID would
>>        previously result in overriding DNS load balancing [RFC1794] by
>>        forcing the destination address with the most bits in common to
>>        be always chosen.  The updated definition allows DNS load
>>        balancing to continue to be used as a tie breaker.
>>
>> I can see this for destination address selection, where you are
>> working from a candidate set provided by a DNS server.
>>
>> But I don't see it for source address selection. If you have multiple
>> source address candidates in the same prefix, they will "fall through"
>> Rule 8 and the implementation then has to make a choice anyway, and
>> that choice doesn't seem able to be related to DNS load balancing.
>>
>> That is, the design rationale for the new CommonPrefixLen() doesn't
>> seem to apply to source address selection, which leads me to think
>> that for source address selection, CommonPrefixLen() should not stop
>> at the source address prefix length.
>>
>> Am I missing something obvious here?

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.

>>
>> 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
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------