[ppml] [address-policy-wg] Those pesky ULAs again

[Jeroen Massar]

(Tony, what where the exact thoughts about the below)

Randy Bush wrote:
>>> ok, i give.  if ula address space is assigned/managed by 
>>> registries, how is it actually different from pi space?
>> Basically ULA space has the same 'routability' as RFC1918 space
> 
> which is a benefit because ...?  rfc 1918 space is a hack to deal with
> an address space shortage.  we are told ipv6 space is effectively
> infinite.  hence we do not need rfc 1918 style space.

The only 'real' benefit I heared up to now was iirc from Tony Hain who
mentioned that it might in corporate cases be handy to be able to
simply have ULA-Central space as the space that is used internally,
and possibly by partner organizations linking in. Thus that you use
fc00::/8 on internal + interconnected networks. While using other
spaces on the internet (that big public thing). The main advantage is
that firewalling becomes easier, as you know that space under fc00::/8
is internal and thus from another company. Splitting routing, doing
firewalling etc thus becomes easier as you know what is public and
what is not.

[..]
>> PI space is expected to be routed globally (if the user of the space
>> wants to).
> 
> as has been amply demonstrated, 1918 space leaks time and again.  so
> this ula stuff will leak time and again.

ULA space should be !A'ed out by routers per default and have a
special switch to enable forwarding for them. Security folks will be
quite happy with that too I guess.

>>> if ipv6 space is effectively infinite (and we once thought ipv4 
>>> space was), then what is the use of ula address space?  why not 
>>> just assign vanilla ipv6 space?

IMHO there should not be a distinction between "PI" and "PA" space.
Both will be broken up into blocks for "Traffic Engineering" purposes
and other such things anyway, as can already be seen in BGP today.
It should all simply be 'address space' and the size of the block
received from the RIR should be based on the amount of address space
they can justify and where possible only 1 such block per
organization. The latter is unrealistic too as when an organization
breaks up they might want to split that block etc yadiyadi. The only
folks who can really stop that from happening is the ISP's themselves.
Any organization with enough cash or importance can get any block
fairly well routed onto the Internet. Lots of ISP's will protest, but
to keep customers they will bend over anyway.

If an ISP wants to keep the number of routes they accept low, they can
already do this easily by taking all the inet6num's which have been
delegated directly from the RIR's and use those to build filters.
Filter list will be insanely large, but then you have the minimum you
want to accept. Currently the classification between PA/PI sort of
helps there as PA is </32 and PI = </48. Then take Gerts filters and
one is fine. At the moment though anyone can simply accept </48 and
should not have any issues in table size yet.

Greets,
 Jeroen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 311 bytes
Desc: OpenPGP digital signature
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20070529/82790d68/attachment.sig>