IETF Logo Mail Archive

Re: [Idr] Using BGP to advertise SD-WAN tunnels end point's private IPv6 addresses. (was registering tunnel types

"Henderickx, Wim (Nokia - BE/Antwerp)" <wim.henderickx@nokia.com> Tue, 06 November 2018 01:06 UTC

Return-Path: <wim.henderickx@nokia.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60BEC12DDA3; Mon, 5 Nov 2018 17:06:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.37
X-Spam-Level:
X-Spam-Status: No, score=-2.37 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IkrP9mAEM1nJ; Mon, 5 Nov 2018 17:06:56 -0800 (PST)
Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00119.outbound.protection.outlook.com [40.107.0.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82D4D126DBF; Mon, 5 Nov 2018 17:06:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PoRygnlaJWGs1pjUln2Hm2+alH3F9NfgRUgxVZ6O+EY=; b=GdA6dyk+Fy+CybiIxo4P8ejSmwbZqTRaWdObYlpnyDjh3t0fuZHu8Y/8vgsFwTi7eJFjpTZqcKJuL4torP7UGFfOGtGdmXvIhX3iib622hdPaJYs16fHY/4hXb38yGUJcdbDybxYAlTNordgZKBa5Z7T0LyE77I4IjHIEoJWqJg=
Received: from DB6PR07MB3477.eurprd07.prod.outlook.com (10.175.234.32) by DB6PR07MB3463.eurprd07.prod.outlook.com (10.170.222.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1294.14; Tue, 6 Nov 2018 01:06:52 +0000
Received: from DB6PR07MB3477.eurprd07.prod.outlook.com ([fe80::5d66:3910:60c:6686]) by DB6PR07MB3477.eurprd07.prod.outlook.com ([fe80::5d66:3910:60c:6686%2]) with mapi id 15.20.1294.032; Tue, 6 Nov 2018 01:06:52 +0000
From: "Henderickx, Wim (Nokia - BE/Antwerp)" <wim.henderickx@nokia.com>
To: Gert Doering <gert@space.net>, Linda Dunbar <linda.dunbar@huawei.com>
CC: "idr@ietf.org" <idr@ietf.org>, "ipv6@ietf.org" <ipv6@ietf.org>, "int-area@ietf.org" <int-area@ietf.org>, Fred Baker <fredbaker.ietf@gmail.com>
Thread-Topic: [Idr] Using BGP to advertise SD-WAN tunnels end point's private IPv6 addresses. (was registering tunnel types
Thread-Index: AQHUdPQP+ZmmSSJuak+m74M0Ps0ZxKVBaBCAgACYwgA=
Date: Tue, 06 Nov 2018 01:06:52 +0000
Message-ID: <4B2F3673-5106-4914-B79F-F3C44013ED06@nokia.com>
References: <4A95BA014132FF49AE685FAB4B9F17F66B18249E@sjceml521-mbs.china.huawei.com> <6E397847-407E-4F69-AD31-E87D0001F603@gmail.com> <4A95BA014132FF49AE685FAB4B9F17F66B182B93@sjceml521-mbs.china.huawei.com> <20181105165959.GB11393@Space.Net>
In-Reply-To: <20181105165959.GB11393@Space.Net>
Accept-Language: nl-BE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.12.0.181014
authentication-results: spf=none (sender IP is ) smtp.mailfrom=wim.henderickx@nokia.com;
x-originating-ip: [110.170.235.6]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DB6PR07MB3463; 6:weuF8YeXtGntx5qlF0wKsBi/t5FfzVpExWS35eGo1pru37V2OxDL0gQ5jbsPMJW+ciJmZ+bVvZXVtJ+ZqQcqnIL1tKFYHboHYS5tjPV4TdnA0bLfGT0V02D27w5QvfGjx/SqZTl5iwBr/aAVkn2bQXHtJ1IZAunb93c8ofHhWMSJHOc8BQdo+IMTNUY8eTmyGRN4gC8PaeLJaXd2NMI1DRnliGa1A48KR7svKbcf5RlyaLPBAAa9KgssKkgOxIRlL2oSKl5I2K68lf8zGaNad8oJLlSXr88UnWBZgMqjThmBBNsAzPoUqVBMd4QTBZLmiwNH4SEmqjVzO1DgqlLroJoBIT+lDZaK8mXQOKHNDf9I+m2cn067ZkaAIxW7ODcVUb7PZES9JksYAzYWl1HyslkpsJ/XEHKBerl+5dtOWDHb2ijqH7lyuelrBJBu3Em1YToM//fPrRbYCvp3SoZYhg==; 5:VO4LgWgu2KrRyWL25mX09USEZAgdQUpQHHs1vI1AxjvmyN7l4kPxvvHLeWCKV+F33zeRUOgC6mO8/l8SWvflfyjrVDrXx5u1/T6WzElb2xYzOtIpX6Yjh8de/TxYOX8w9BmS7fPdBHz/fAx+2/aZG/3mzL0D/aPAcz5LrcYo8bI=; 7:yjTN9LdnJOSPCUylaP5GdMfWhj8rROh0B0R8dUNZf0zASpkbF+KPbUARdmbYYpTfN4UPUsHJzVHF0sLpVrAFS6G+ItzpAiPly4pP/eIhV5s40bv5xeOMRAzZmVdasCGNnjgrJPpZHf3JX3TfMFc6xQ==
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: a9d2e81d-67d0-4865-90df-08d643842375
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(5600074)(711020)(4618075)(4534185)(7168020)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7167020)(7193020); SRVR:DB6PR07MB3463;
x-ms-traffictypediagnostic: DB6PR07MB3463:
x-microsoft-antispam-prvs: <DB6PR07MB34632FFFD2FF2E3ADF8EF45F83CB0@DB6PR07MB3463.eurprd07.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231382)(11241501184)(806099)(944501410)(52105095)(3002001)(10201501046)(93006095)(93001095)(6055026)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123560045)(20161123564045)(201708071742011)(7699051)(76991095); SRVR:DB6PR07MB3463; BCL:0; PCL:0; RULEID:; SRVR:DB6PR07MB3463;
x-forefront-prvs: 0848C1A6AA
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(366004)(136003)(376002)(396003)(39860400002)(189003)(199004)(305945005)(97736004)(6306002)(446003)(93886005)(5660300001)(11346002)(2906002)(76176011)(229853002)(6436002)(6512007)(6486002)(486006)(2616005)(7736002)(186003)(4326008)(316002)(476003)(53936002)(71200400001)(83716004)(55236004)(71190400001)(6506007)(66066001)(25786009)(39060400002)(81156014)(86362001)(33656002)(478600001)(58126008)(6116002)(110136005)(102836004)(36756003)(99286004)(966005)(3846002)(26005)(6246003)(14454004)(106356001)(105586002)(8676002)(256004)(8936002)(68736007)(54906003)(14444005)(81166006)(2900100001)(82746002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6PR07MB3463; H:DB6PR07MB3477.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: bwMQS/KJF9AIkr+Q1JDMfBj+ufbCmvURkNlSsZS1nu0ZJSPppSrNjv6k8XLBJgxaUQpVWPb/3Cp/NPZ4Xje2kaKWjgil3URVFjznN64Hma7guxs1nWdLWdFNgqg2DS8M0SxJ/Z5KCc39ckYVZ93amXBDhlLuBHlVEQC0L2CUwGNh1sMYjvU1CvzVtdq4jnI8y8AHrNK1VfDrV0vIqlR5sSJQVWq174+GswfjipWBrQk7i8P4hNxPylqn2WMBppEY/VVaSebr9Lplwtck44v9ZtGM3WLMkHsqVfIJw2coGuhUYTh1x5bxBG39Wa3uuafbV8+TNXqoOIh5719zhF7LzAaq8t3MbbqDk9tvtRfoNN0=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <91507FF468EF8448A1F2BBCC26D6F073@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a9d2e81d-67d0-4865-90df-08d643842375
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Nov 2018 01:06:52.7444 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR07MB3463
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/FAh75AVXoNdMbMjeAFS27e53WRU>
Subject: Re: [Idr] Using BGP to advertise SD-WAN tunnels end point's private IPv6 addresses. (was registering tunnel types
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Nov 2018 01:06:58 -0000

Even a NAT64 is not needed. What we do now is we go to a GW (lets call it like this for now) and the GW rewrites the outer header of the tunnel srcIP and dstIP from v4 to v6 or vice versa. It is kind of decap/encap operation on the outer header as if you terminate the tunnel and reinitiate the tunnel. No NAT64 required.



On 06/11/2018, 00:00, "Idr on behalf of Gert Doering" <idr-bounces@ietf.org on behalf of gert@space.net> wrote:

    Hi,
    
    On Mon, Nov 05, 2018 at 10:40:36AM +0000, Linda Dunbar wrote:
    > If a CPE-1 has private IPv6 addresses for its ports behind NAT, and CPE-2 has IPv4 address, can CPE-1 communicate with CPE-2 by the NAT's IPv4 address? 
    
    Since there are no private IPv6 addresses, no.
    
    Generally speaking, if CPE1 has only IPv6 addresses and CPE2 has only
    an IPv4 address, the answer is no as well, unless there is a NAT64 
    involved somewhere.
    
    Gert Doering
            -- NetMaster
    -- 
    have you enabled IPv6 on something today...?
    
    SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael Emmer
    Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
    D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
    Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279
    
    _______________________________________________
    Idr mailing list
    Idr@ietf.org
    https://www.ietf.org/mailman/listinfo/idr

v2.23.0 | Report a Bug | By Email