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

Karl Auer <> Tue, 31 July 2012 01:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2159C21F8517 for <>; Mon, 30 Jul 2012 18:46:10 -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 F+DVKUiSnUyn for <>; Mon, 30 Jul 2012 18:46:09 -0700 (PDT)
Received: from ( [IPv6:2001:44b8:8060:ff02:300:1:2:7]) by (Postfix) with ESMTP id CDD3221F8516 for <>; Mon, 30 Jul 2012 18:46:07 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApMBAA44F1CWZX+7/2dsb2JhbAANOIV4tw8BAQEDASNbCwsYKgICVwYTiAenOm6TKIJCjwOBEgOgVYdx
Received: from (HELO []) ([]) by with ESMTP; 31 Jul 2012 11:16:06 +0930
Subject: RE: question about draft-ietf-6man-rfc3484bis-06.txt and CommonPrefixLen()
From: Karl Auer <>
To: "" <>
In-Reply-To: <>
References: <1343085852.2796.201.camel@karl> <1343524489.3497.94.camel@karl> <>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-p8mHU00+T968FwkZPnx/"
Date: Tue, 31 Jul 2012 11:46:05 +1000
Message-ID: <1343699165.26898.113.camel@karl>
Mime-Version: 1.0
X-Mailer: Evolution 2.30.3
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: Tue, 31 Jul 2012 01:46:10 -0000

On Tue, 2012-07-31 at 00:28 +0000, Dave Thaler wrote:
> The bits in the interface identifier are not indicative of goodness or
> appropriateness or whatever.

Firstly, thanks for the extensive explanation.

I realise now that I was confusing two comparisons - the comparison of
an address with a prefix in the policy table and the comparison of two
addresses with each other.

Comparing an address with a prefix in the policy table must continue for
as many bits as are specified for the prefix in the policy table.

Is that understanding correct? If so, given the redefinition of
CommonPrefixLen(), do the definitions of Label() and Precedence() need
to make this point explicit?

> 1) explicitly add Rule 9 which is already implied.

Is it? In the fourth paragraph of Section 5, the draft says

     If the eight rules fail to choose a single address,
     the tie-breaker is implementation-specific.

I suppose one could say that since the draft does not specify an initial
ordering, the ordering is implementation-specific, so therefore the
tie-breaker is implementation specific :-) but that's not really the
point. If the draft wants the ordering to be the tie-breaker I think it
has to say so explicitly, as that would then exclude other tie-breaking

It seems to me that the draft should be left as it is in this respect,
and thus allow an implementation to use the original ordering if it
wants to, but not demand it or expect it.

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