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/
[address-policy-wg] Input request for the PI Transfer policy
- Previous message (by thread): [address-policy-wg] Input request for the PI Transfer policy
- Next message (by thread): [address-policy-wg] Input request for the PI Transfer policy
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Tore Anderson
tore at fud.no
Tue Mar 25 14:23:22 CET 2014
* Elvis Velea > First of all, because the other RIRs (APNIC&ARIN) also have a /24 limit > for Inter-RIR transfers and I do hope that our region will eventually > have an Inter-RIR transfer policy compatible with theirs .. so, for > consistency with the others. The Inter-RIR transfer policy to be could simply say that if the other RIR has a minimum size limitation (or any other limitation really), then that limitation applies for transfers to/from that RIR, could it not? Seems to me that the fewer rules and restrictions we put in place in our end, the smaller the risk of any irreconcilable incompatibilities with other the other RIRs' policies. > Secondly, because most of the routing is done by filtering at the /24 > level and even though not all the IPv4 space is used on the internet and > publicly advertised, it seems to be the limit already adopted by most of > the ISPs. That is happening completely independent of RIPE address policy today and the practice will in all likelihood continue tomorrow too, regardless of what policy we might pass. > Thirdly, setting up reverse dns for blocks lower than /24 requires that > any minor changes for reverse dns would need to involve the RIPE NCC. The same is true for assignments smaller than /24 today, which already exist; we didn't have a minimum PI assignment size, so the NCC has issued quite a few >=/25s already. If those >=/25 PI assignments issued by the NCC aren't a problem today, I don't see why transferred >=/25 PI assignments should be one tomorrow. > Lastly, allowing any level of fragmentation could lead to an exploding > IPv4 routing table (now at almost 500k routes). I'm not saying that > adding an (arbitrary) transfer limit like the /24 would stop the routing > table growth. See my response to your «secondly»... Also I think that concerns over an «exploding» routing table are unfounded in reality. I mean we've only had 233 transfers _in total_ so far, and that's only of blocks that the recipient could reasonably expect to route on the internet. How many people are we seriously expecting to want to transfer these mostly useless >=/25 PI assignments to themselves? Anyone at all? I seriously doubt that those weirdos are numerous enough to worry about in the the slightest... Tore
- Previous message (by thread): [address-policy-wg] Input request for the PI Transfer policy
- Next message (by thread): [address-policy-wg] Input request for the PI Transfer policy
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]