Re: [addr-select-dt] Fwd: draft slides for behave meeting ( learning NAT64 prefix)

Tim Chown <> Mon, 26 July 2010 09:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1962B3A68C3 for <>; Mon, 26 Jul 2010 02:23:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.413
X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KNVJ7CuVDOaU for <>; Mon, 26 Jul 2010 02:23:50 -0700 (PDT)
Received: from ( [IPv6:2001:630:d0:f102::25e]) by (Postfix) with ESMTP id 21CDE3A68CE for <>; Mon, 26 Jul 2010 02:23:49 -0700 (PDT)
Received: from (localhost []) by (8.13.8/8.13.8) with ESMTP id o6Q9O70X021565 for <>; Mon, 26 Jul 2010 10:24:07 +0100
X-DKIM: Sendmail DKIM Filter v2.8.2 o6Q9O70X021565
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple;; s=200903; t=1280136248; bh=bWqC6sgWpwE0epcumBYSqeUiUD0=; h=Subject:References:From:In-Reply-To:Date:To:Mime-Version; b=Lzw03DnOtWwl6QI7xMa0jj8ATaCPqR1PgRnIX/IMXANzI+i737AE1IPx5XswrRFu8 sB5JOTFBsLXtleSa44TzFdZ/FzAwAlC5GMj7gbfCcQP8jvtj2JxlmMw4XmMO0dFzSP X4MLXs7n4vYyY8yhfgVXrMK9XNi5BPaCXrE5E944=
Received: from ( [2001:630:d0:f102::25d]) by ( [2001:630:d0:f102::25e]) envelope-from <> with ESMTP id m6PAO705400335416b ret-id none; Mon, 26 Jul 2010 10:24:08 +0100
Received: from ( []) by (8.13.8/8.13.8) with ESMTP id o6Q9O5jk003605 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <>; Mon, 26 Jul 2010 10:24:05 +0100
References: <> <> <>
From: Tim Chown <>
Content-Type: multipart/alternative; boundary=Apple-Mail-6--966149433
In-Reply-To: <>
Message-ID: <EMEW3|545b2a39cb81f995da1b6fa625910df2m6PAO703tjc||>
Date: Mon, 26 Jul 2010 10:24:04 +0100
Mime-Version: 1.0 (Apple Message framework v1081)
X-Mailer: Apple Mail (2.1081)
X-ECS-MailScanner: Found to be clean, Found to be clean
X-smtpf-Report: sid=m6PAO7054003354100; tid=m6PAO705400335416b; client=relay,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0
X-ECS-MailScanner-Information: Please contact the ISP for more information
X-ECS-MailScanner-ID: o6Q9O70X021565
Subject: Re: [addr-select-dt] Fwd: draft slides for behave meeting ( learning NAT64 prefix)
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IPv6 Address Selection Design Team <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 26 Jul 2010 09:23:52 -0000

One point is what is the 'best' default policy is for 3484-bis?    Preferring native IPv4 over NAT64 seems sensible, just as preferring IPv4 over 6to4 or Teredo would be, but I don't know the context of your discussion.

The other is that this shows again the value of progressing the enterprise policy distribution mechanism so whatever 3484-bis says when a new issue arises the enterprise can handle it via the mechanism offering updated policy to hosts.


On 26 Jul 2010, at 07:23, Arifumi Matsumoto wrote:

> Hi all,
> I've forwarded the following thread from Teemu.
> This looks like about NAT64 prefix prioritization especially in comparison with IPv4.
> Maybe I should include this issue in the slides for 6man.
> Any thoughts ?
> Begin forwarded message:
>> From:  <>
>> Date: 2010年7月23日 19:08:54JST
>> To:  <>om>, <>
>> Cc: <>om>, <>om>, <>
>> Subject: RE: draft slides for behave meeting ( learning NAT64 prefix)
>> Hi,
>>> Keep in mind that I am trying to tease out what "more" is there, so we
>>> can get it into the presentation on Monday.
>> Hopefully the community comes up with ideas/scenarios as well - quite like Matthew Kaufman commented on the list already.
>>> If it's just a preference thing, adjusting RFC3484 rules (in the
>>> connection manager, or elsewhere) to prefer IPv4 over synthetic
>>> IPv6 addresses would do the trick.
>> Right, Arifumi probably is the best person to tell if 6man's source address selection design team has already taken into account the case where addresses matching to NSP (and WKP) should (perhaps) have lower preference? 
>>> But it seems it is more than a preference thing.  For reasons that
>>> I do not fully yet grasp, you want to know on a response-by-response
>>> basis if an address is synthesized, by having additional bits sent
>>> to the handset.
>> This is part of pros and cons of different approaches. If a network is using multiple different prefixes for NAT64, then it might be easier to have the indication in each reply rather than communicate set of prefixes for hosts?
>> Best regards,
>> Teemu
> _______________________________________________
> addr-select-dt mailing list