Subject: Re: [v6ops] Comments on ULA draft

From: "Liubing (Leo)" <[email-masked]>
Date: Thu, 20 Jul 2017 12:56:09 +0000

Hi Lorenzo,

Thanks much for your summary in the mailing list. Replies inline.

发件人: Lorenzo Colitti [mailto:[email-masked]]
发送时间: 2017年7月20日 14:21
收件人: [email-masked] WG <[email-masked]>
抄送: [email-masked]
主题: Comments on ULA draft

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.
[Bing] No problem for me if it doesn’t exceed the level of an informational document.

  1.  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.
[Bing] I guess the firewall at the edge of public and private can simply block all FD::/ prefix? 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?
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?.

  1.  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.
[Bing] Ok, thanks.

  1.  Due to #2 and #3, it may well be simpler to use global space and just add a firewall.
[Bing] ULAs are mostly for

1)       automation, that some mechanisms can self-generate valid IPv6 addresses without any provisioning. E.g. BTMM(https://tools.ietf.org/html/rfc6281#section-6.3), and Anima ACP addressing(https://tools.ietf.org/html/draft-ietf-anima-autonomic-control-plane-08#section-6.10).

2)       Instant usage without applying to LIR/RIR.
              ULAs don’t have any security advantages than PA addresses. For firewall policies, I see no extra burden according to my poor experience. If there is, I’d like to include it in the document. Thanks.
Best regards,
Bing

Regards,
Lorenzo

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 20 Jul 2017 15:09:32 +0200

On Thu, Jul 20, 2017 at 2:56 PM, Liubing (Leo) <[email-masked]>
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.

> 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.

> 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.