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 ]
Per Heldal
heldal at eml.cc
Wed May 30 18:43:44 CEST 2007
On Wed, 2007-05-30 at 10:48 -0400, Marshall Eubanks wrote: > On May 30, 2007, at 4:33 AM, Per Heldal wrote: > > > If you want to endorse PI for "private" use please also consider > > that it > > leaves blocks wide open to abuse. Separate ULA-C space can easily be > > filtered, but how do you easily prevent hijacking of unannounced > > PI-prefixes should such private blocks become as commonplace as > > rfc1918-space? > > How do you prevent it now, in IPv4 ? I filter private addresses ;) (rfc1918). > (I know several companies with > addressable blocks for > internal use, and so I suspect that this is not that rare.) I expect those relatively few with "hidden" V4 PI to be elegible for V6 PI and that they will continue a similar practise with V6. My concern is directed at those who promote unannounced public V6 blocks as a mass-replacement for rfc1918 when efforts imho are better spent on solutions to eliminate the use of NAT and private space. Btw, holding back part of a PI block is also going to create problems. >From a transit-provider perspective I find it reasonable to filter anything smaller than RIR-allocated blocks . I.e. anything longer than a /48 from PI-land is filtered. A couple extra bits may be accepted if the as-path-length is 2 or less (for TE purposes). Similar goes for PA-land. Where does that leave a /48 split split up to keep parts of it "secret"? //per
- 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 ]