This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/address-policy-wg@ripe.net/
[ppml] [address-policy-wg] Those pesky ULAs again
- Previous message (by thread): [ppml] [address-policy-wg] Those pesky ULAs again
- Next message (by thread): [ppml] [address-policy-wg] Those pesky ULAs again
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Jeroen Massar
jeroen at unfix.org
Tue May 29 11:01:15 CEST 2007
(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: </ripe/mail/archives/address-policy-wg/attachments/20070529/82790d68/attachment.sig>
- Previous message (by thread): [ppml] [address-policy-wg] Those pesky ULAs again
- Next message (by thread): [ppml] [address-policy-wg] Those pesky ULAs again
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]