[v6ops] Comments on ULA draft
Lorenzo Colitti <lorenzo@google.com> Thu, 20 July 2017 12:21 UTC
Return-Path: <lorenzo@google.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 4412A131C06 for <v6ops@ietfa.amsl.com>; Thu, 20 Jul 2017 05:21:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 s5V5KhEyu6Wm for <v6ops@ietfa.amsl.com>; Thu, 20 Jul 2017 05:21:42 -0700 (PDT)
Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58F4912EC30 for <v6ops@ietf.org>; Thu, 20 Jul 2017 05:21:42 -0700 (PDT)
Received: by mail-it0-x233.google.com with SMTP id v127so14989311itd.0 for <v6ops@ietf.org>; Thu, 20 Jul 2017 05:21:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=WtDDF2tISolSHBc3DVsRMs3T3eR7FUCiTIl6EQHhv8E=; b=pjsPxDr1McoZ5cM41ufjgOpklQSKCrYiL9kTCa0zfiLDtSA44vBBlKXK9Pr7QldyZy yEmHjMHXSzJkr7gGBTWw3q2n89su1yQE5D/sTPERco8ZItKF9zbX5IpDC/hnXKjd6921 N/5zAJ/GVW+A8U6Gi9HxqBELq8QTKQtLabLloo3XGU7VWBFc85oKAKx6Zi2KClTYhHFE x2lYSz4DsvvkHdLs5X9paA/5GcLz3WSx3LO1+RVXFqg9FvDndzfwF2BDU5qGwxZFuVF2 38vM27xsjWi119xHKJowYbeY5zmWaf+G+sTSuUhm2ssB0ZBmQxylzJEEZYkmqQdj4LVn 2fVg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=WtDDF2tISolSHBc3DVsRMs3T3eR7FUCiTIl6EQHhv8E=; b=LluukWqkzUzVw7JyS368HQe5FNFzcdKYy0W2+oIlleuYw/50UFOCqwqVWKZRBx1lck oj0oniD0c5mJt9YOAYlUPDyNLzJplxxAnpcIGf4t4NlXU/aI8kEBFnL5SS6KZOqTS+HO xeE4zs0czEZ0inBCZPhFKFsPBYIYaOAS0vnfKJSRJatsr5mvBPSDqUXj2BUlBxP5Lpug GEhUf2MrCrClALrktbhkwu8Xq2ZPSQhod+noZjrBl1LwVbuzxSqUnxwJGiGwoSO3QNUP fgX0Ykb6kgUPePszoTRGy4ATYwmuBN7sQIxkBoI5bKjHGWiTdu18/tI5j8woxF8BTAtb 8M6A==
X-Gm-Message-State: AIVw110RfeTHtip+xOZkX3rbg1Bb5RnsQejNzThTIvXzUb54Wg+emEHL 3LtL9fF6NggheYFrRx5qX5Ac3ZgRNKxcfJk=
X-Received: by 10.36.4.139 with SMTP id 133mr3217168itb.142.1500553301148; Thu, 20 Jul 2017 05:21:41 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.195.137 with HTTP; Thu, 20 Jul 2017 05:21:20 -0700 (PDT)
From: Lorenzo Colitti <lorenzo@google.com>
Date: Thu, 20 Jul 2017 14:21:20 +0200
Message-ID: <CAKD1Yr1p5Lkx=N5O+MHaj1MMKmbUi+bEf7YeiVrqbY3redp3pg@mail.gmail.com>
To: "v6ops@ietf.org WG" <v6ops@ietf.org>
Cc: draft-ietf-v6ops-ula-usage-considerations@ietf.org
Content-Type: multipart/alternative; boundary="001a113fe1e27c05bc0554beca60"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/_wdTzjEgeVIuiDoflMVN1SL1Xx8>
Subject: [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 12:21:49 -0000
Repeating the comments at the mike: 1. As clearly shown in the presentations slides, and as said by others, there will continue to be is substantial opposition to any document unless it says that ULA+NPTv6 deployments are NOT RECOMMENDED. The current text in section 4.3 is very far from making such a statement. 2. The document needs to be clear that because ULAs MUST be generated randomly (per RFC 4193), they are not aggregatable. Thus, developing ULA firewall policies is very complex because there is no way to ensure that /48s with similar security policies have adjacent address space. Even if ULA is initially deployed in a network that has only two zones ("public" and "private") network growth or mergers with other networks will cause firewall policies to become complex and have lots of holes. 3. The document should say that even though ULAs are typically not announced externally, any network that is adjacent to the ULA network can send and receive packets from ULA addresses unless there is a firewall rule that blocks such packets. For well-connected networks that have lots of peers, that can be a large attack surface. 4. Due to #2 and #3, it may well be simpler to use global space and just add a firewall. Regards, Lorenzo
- [v6ops] Comments on ULA draft Lorenzo Colitti
- Re: [v6ops] Comments on ULA draft Liubing (Leo)
- Re: [v6ops] Comments on ULA draft Lorenzo Colitti
- Re: [v6ops] Comments on ULA draft Liubing (Leo)
- Re: [v6ops] Comments on ULA draft Brian E Carpenter