Re: draft-ietf-ipv6-ula-central-02.txt

[Jeroen Massar <[e-mail]>]

[e-mail] wrote:
>> It is more about creating a address space that can be used 
>> for OTHER thing than the DFZ-way of thinking Internet we have now.
> 
> Up until now, I've been on the fence regarding ULA-centrally-registered
> address space, but after several comments in the past two days, I now
> support defining these addresses.

My views are also changing, toward positive, based on the discussions,
but there is a big but: the draft needs to say those things too.

The description has to be heavily updated to explain really WHY this
type of addresses (should) exist and for what usages. Also I am pretty
convinced that the naming has to be changed. The RFC4193 ULA naming is
quite accurate, but for the kind of usage that has been discussed
recently ULA is not a good name. Also the draft should very clearly
outline the pro's and con's that this type of address space has for
potential users of it. That they can be used as EID's at a certain point
in time is also that should be documented in the draft.

As such, I am awaiting the new draft.

> Other factors that I think help make the case:
> 
> 1) The RIR system is already in place to deal with DFZ grey areas. If we
> delegate the central registry function to the RIRs, they can deal with
> the details of how such addresses are handed out (automatically or on
> demand), charges for maintaining the registry and ip6.int services, and
> sorting out the issues of non-aggregation and global routing table
> entries.

You most definitely meant ip6.arpa there instead of ip6.int which was
deprecated quite some time ago. Indeed, the RIR's are already in place
if something to the effect of the proposed address space would ever come
to be then they are the places that should be the registries for it.
Inventing new structures for that would not be helpful at all.

> 2) These ULA addresses provide an additional layer of security in a
> layered security model. If I use my PI addresses for secret internal
> infrastructure, I must block those ranges in my firewall.

Or simply not route them at all. I don't really see this is a benefit.
It is only a benefit against so called fat fingers, but if you have that
problem there are bigger problems at hand, especially in an area where
security is to be required.

> Networks which
> I connect to will likely not block these ranges, so I have one layer of
> security. If I use ULA addresses, then the vast majority of other
> networks will block the entire ULA range, thus giving me an additional
> layer of security. If I need to use ULA addresses to talk to a peer, we
> can both punch holes in our filters/firewalls.

Maybe to reflect the above, the draft should definitely state that
firewalls should per default at least propose to block these ranges.

> In general, it seems to me that the benefits fall on the enterprise
> network side, and the possibly disadvantages fall on the ISP side. The
> IETF needs to provide technology that supports all users of IPv6. Since
> there are other mechanisms outside the IETF to deal with the ISPs'
> issues, I think we need to go ahead with ULA centrally-registered.

The question here still remains though: how really different is this
from "PI". In effect it is non-DFZ-PI space that is being defined here.
RIR's themselves could thus also set aside a /20 or something and
allocate /40-/48's from that block for that purpose and state "currently
these might be routable, but in the future they will not be".
Which is quite less of an addressing burn than this.

[..]
> Is Paul's superceding that or is there a merge in process?

I understood that he is busy updating it and tried to submit it, though
submitted it after the -00 deadline. Which means that for the time being
it can't be updated :(

Greets,
 Jeroen

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------