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] 2019-05 New Policy Proposal (Revised IPv4 assignment policy for IXPs)
- Previous message (by thread): [address-policy-wg] 2019-05 New Policy Proposal (Revised IPv4 assignment policy for IXPs)
- Next message (by thread): [address-policy-wg] 2019-05 New Policy Proposal (Revised IPv4 assignment policy for IXPs)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Nick Hilliard
nick at foobar.org
Wed May 29 18:39:07 CEST 2019
Gert Doering wrote on 29/05/2019 16:45: > IXPs say they need globally unique space, and they are the experts here. From an architectural point of view, it's a good idea to use publicly registered numbering resources when interconnecting with third parties. IXPs are an extreme case of this because the same resource block is used to connect to multiple parties at the same time. One of the reasons this can cause problems is that the address block of the peering LAN often ends up redistributed in the IXP participant's routing tables. Lots of organisations redistribute rfc1997 address space internally in their own networks for their own purposes, so if this conflicts with the IXP peering LAN address block, the organisation is going to end up with connectivity problems. There are other reasons this can cause problems, but this is one of the more obvious ones. Nick
- Previous message (by thread): [address-policy-wg] 2019-05 New Policy Proposal (Revised IPv4 assignment policy for IXPs)
- Next message (by thread): [address-policy-wg] 2019-05 New Policy Proposal (Revised IPv4 assignment policy for IXPs)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]