RFC3484-revise and NAT64 Well-Known Prefix

<teemu.savolainen@nokia.com> Sun, 27 March 2011 13:19 UTC

Return-Path: <teemu.savolainen@nokia.com>
X-Original-To: ipv6@core3.amsl.com
Delivered-To: ipv6@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25CAD3A67E3; Sun, 27 Mar 2011 06:19:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.689
X-Spam-Level:
X-Spam-Status: No, score=-2.689 tagged_above=-999 required=5 tests=[AWL=-0.091, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GSA049oXW9Gw; Sun, 27 Mar 2011 06:19:10 -0700 (PDT)
Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by core3.amsl.com (Postfix) with ESMTP id 5070428C100; Sun, 27 Mar 2011 06:19:10 -0700 (PDT)
Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-da02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p2RDKjqP012355; Sun, 27 Mar 2011 16:20:46 +0300
Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sun, 27 Mar 2011 16:20:35 +0300
Received: from 008-AM1MMR1-001.mgdnok.nokia.com (65.54.30.56) by NOK-am1MHUB-01.mgdnok.nokia.com (65.54.30.5) with Microsoft SMTP Server (TLS) id 8.2.255.0; Sun, 27 Mar 2011 15:20:35 +0200
Received: from 008-AM1MPN1-036.mgdnok.nokia.com ([169.254.6.195]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi id 14.01.0270.002; Sun, 27 Mar 2011 15:20:34 +0200
From: teemu.savolainen@nokia.com
To: ipv6@ietf.org, behave@ietf.org
Subject: RFC3484-revise and NAT64 Well-Known Prefix
Thread-Topic: RFC3484-revise and NAT64 Well-Known Prefix
Thread-Index: AcvsgcCRXbnjiKSUSuKTwnQkrPt+Hw==
Date: Sun, 27 Mar 2011 13:20:34 +0000
Message-ID: <916CE6CF87173740BC8A2CE443096962014C5D@008-AM1MPN1-036.mgdnok.nokia.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.162.93.108]
Content-Type: multipart/alternative; boundary="_000_916CE6CF87173740BC8A2CE443096962014C5D008AM1MPN1036mgdn_"
MIME-Version: 1.0
X-OriginalArrivalTime: 27 Mar 2011 13:20:35.0901 (UTC) FILETIME=[C1F24ED0:01CBEC81]
X-Nokia-AV: Clean
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Sun, 27 Mar 2011 13:19:11 -0000

Hi,

I discussed shortly with Arifumi about RFC3484 default policy table updates and NAT64 WKP, i.e. whether the default policy table should take a stand on 64:ff9b::/96 preference.

It seemed to us that default policy table does not necessarily have to, as it could be ok to handle addresses with WKP similarly to global IPv6 addresses. Furthermore, the default policy table anyway cannot cover Network-Specific Prefixes.

Hence prefixes used for protocol translation would be handled like global IPv6 addresses unless something different is configured via policy distribution mechanism? And this should perhaps be documented into the RFC3484-revised.

Best regards,

                Teemu