IETF Logo Mail Archive

Re: [v6ops] Comments on ULA draft

"Liubing (Leo)" <leo.liubing@huawei.com> Thu, 20 July 2017 15:32 UTC

Return-Path: <leo.liubing@huawei.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82B69131B11; Thu, 20 Jul 2017 08:32:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 kOrhf8MFAAqt; Thu, 20 Jul 2017 08:31:58 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EE25131473; Thu, 20 Jul 2017 08:31:57 -0700 (PDT)
Received: from 172.18.7.190 (EHLO LHREML711-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DRQ60594; Thu, 20 Jul 2017 15:31:55 +0000 (GMT)
Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 20 Jul 2017 16:31:54 +0100
Received: from NKGEML514-MBX.china.huawei.com ([fe80::40a8:f0d:c0f3:2ca5]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Thu, 20 Jul 2017 23:31:49 +0800
From: "Liubing (Leo)" <leo.liubing@huawei.com>
To: Lorenzo Colitti <lorenzo@google.com>
CC: "v6ops@ietf.org WG" <v6ops@ietf.org>, "draft-ietf-v6ops-ula-usage-considerations@ietf.org" <draft-ietf-v6ops-ula-usage-considerations@ietf.org>
Thread-Topic: Comments on ULA draft
Thread-Index: AdMBao5fmh7aobAAS9+r844FjcqjQQ==
Date: Thu, 20 Jul 2017 15:31:48 +0000
Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F45C2FB1F0C@nkgeml514-mbx.china.huawei.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.68.63]
Content-Type: multipart/alternative; boundary="_000_8AE0F17B87264D4CAC7DE0AA6C406F45C2FB1F0Cnkgeml514mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.5970CCEC.0007, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 1743d57c20dee54244f48e944840cebe
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/g8zvIgKuAqkuMO0OdlAq0yUN50I>
Subject: Re: [v6ops] Comments on ULA draft
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 20 Jul 2017 15:32:06 -0000

Thanks for your response Lorenzo, pls see inline [Bing2].

发件人: Lorenzo Colitti [mailto:lorenzo@google.com]
发送时间: 2017年7月20日 15:10
收件人: Liubing (Leo) <leo.liubing@huawei.com>
抄送: v6ops@ietf.org WG <v6ops@ietf.org>; draft-ietf-v6ops-ula-usage-considerations@ietf.org
主题: Re: Comments on ULA draft

On Thu, Jul 20, 2017 at 2:56 PM, Liubing (Leo) <leo.liubing@huawei.com<mailto:leo.liubing@huawei.com>> wrote:

[Bing] I guess the firewall at the edge of public and private can simply block all FD::/ prefix?

That only works if there are exactly two zones: public and private. As soon as you have a third zone (e.g., if there is a merger, or a different type of network), every /48 needs to have its own security policy.
[Bing2]: If zones are connected through the public network, the zones communication should not over ULA packet, since the public network would drop the ULA packets in any case. If admins want to do ULA packets across domains, they need to make the packets over some L3/L2 tunnels; or just add a PA prefix. Thus, the edge firewalls between each zone and the public zone, can still apply the blocking FD::/ rule.
For internal firewalls, if it needs to block some specific addresses/prefixes, either using ULAs or PAs, admins both need to configure specific rules, so I think ULAs and PAs are just equal on this point?

They're not equal because with global space, multiple /48s that have the same security policy can be grouped into a single shorter prefix that only requires one firewall rule.
[Bing2]: Yes. That’s something I can add into the document.

Btw, the admins could randomly generated a single one 48/ ULA prefix, and announce it internally, there are still 16bit for sub-organization. So, this could be considered as kind of aggregation?.

Yes, but only for a small network.
[Bing2] I don’t quite understand why only for small networks? Is it because the 16bit is not enough for a large organization to divide sub-networks?

Best regards,
Bing

v2.23.0 | Report a Bug | By Email