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

Karl Auer <> Mon, 23 July 2012 23:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8F65E11E80E7 for <>; Mon, 23 Jul 2012 16:24:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Kej8q9DPzkvW for <>; Mon, 23 Jul 2012 16:24:20 -0700 (PDT)
Received: from ( [IPv6:2001:44b8:8060:ff02:300:1:2:7]) by (Postfix) with ESMTP id 9C57411E80F3 for <>; Mon, 23 Jul 2012 16:24:18 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApIBACbcDVCWZX+7/2dsb2JhbAANOIVvt0KBCwImAl8TsGhuknaBIIEhjk2BEgOgVodx
Received: from (HELO []) ([]) by with ESMTP; 24 Jul 2012 08:54:15 +0930
Subject: question about draft-ietf-6man-rfc3484bis-06.txt and CommonPrefixLen()
From: Karl Auer <>
To: IETF IPv6 <>
Content-Type: text/plain; charset="UTF-8"
Date: Tue, 24 Jul 2012 09:24:12 +1000
Message-ID: <1343085852.2796.201.camel@karl>
Mime-Version: 1.0
X-Mailer: Evolution 2.30.3
Content-Transfer-Encoding: 7bit
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 23 Jul 2012 23:24:20 -0000

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?

Regards, K.
Karl Auer (

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