Hi Per,
Regardless of the listed arguments one may also question IETFs role in
the definition of (any) ULA as there is no technical reason why
such an
address-block must be tagged 'special'.
Thanks for raising this point. Others have made a similar argument
in the past, and it should definitely be added to the document. I
didn't fully understand this point before, but I think I get it now.
The key point, I think, is that there is no direct connection between
IETF address block allocations and registry policy. In this
particular case, the registries could decide to assign ULA-C
equivalents from the regular address pool if they thought that would
be a good idea, or they could choose not to register ULA-Cs,
regardless of an IETF document allocating a particular address block
for this purpose.
If the IETF wants to provide
guidance to the policy-process such should be no stronger than BCPs
(like rfc1918), not technical standards (rfc4193). The regional
registries, through the ICANN/ASO and IANA, may or may not choose to
implement policies that support some form of ULA. There's no need for
the IETF to dictate that process.
I don't think it makes sense to include this argument regarding all
ULAs in the current document, because RFC 4193 has already been
published and the case for/against locally-allocated ULAs is outside
the scope of this document. Personally, I think that there is a big
difference between defining locally-assigned ULAs and defining ULA-
Cs. In the case of locally-assigned ULAs, RFC 4193 effectively
removed a block of addresses (the locally-assigned ULAs starting with
FD00::/8) from the set of addresses that are registry-assigned,
whereas for ULA-Cs we would by trying (perhaps unsuccessful, as you
point out) to set central registration policies for a group of
addresses.
Also consider the signals such
standards communicate to manufacturers. Misleading standards and
policies have led vendors to introduce artificial limitations in
hardware and software in the past (example: 240/4). Do we really want
that?
This is a very good point, and I think it should be included in the
document separate from your first argument. The installation of
default filters to prevent routing ULAs, for example, might have
undesirable consequences later.
I think that Geoff Huston has made the same (or a similar) argument
when he has indicated that it is architecturally unsound to associate
routing properties with a specific address block. There is no
inherent guarantee that any registry-assigned address block will be
routable (you need to arrange for routing with your ISP), so there is
no need to create a new registry-assigned address block to remove
that non-existent guarantee.
I'll capture this argument in the next version of my document, as
well as you first point.
Let me know if I seem to be misunderstanding what you've said.
Thanks!
Margaret
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
