1 / 16

IPv4 IXP Address Policy

IPv4 IXP Address Policy. APNIC Policy SIG Meeting Taipei, August 2001 Philip Smith <pfs@cisco.com>. The Problem. IXPs require IPv4 Address Space For transit LAN to which participants/members connect their routers

kedma
Download Presentation

IPv4 IXP Address Policy

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. IPv4 IXP Address Policy APNIC Policy SIG Meeting Taipei, August 2001 Philip Smith <pfs@cisco.com>

  2. The Problem • IXPs require IPv4 Address Space • For transit LAN to which participants/members connect their routers • For services LANs which host systems and infrastructure necessary to run the IXP • APNIC has no criteria for assigning IPv4 address space to IXPs

  3. Background • IXPs are using address space from a variety of sources: • Some apply to APNIC and fail under minimum criteria rules • Some receive address space from membership which can lead to conflicts of interest • Some receive address space from the Exchange Point address block administered by EP.net • etc

  4. Current Status • APNIC • Has no distinct policy for IXPs • ARIN • Makes micro assignments no smaller than /24 to critical infrastructure: IXPs, RIRs, gTLD, ccTLD and ICANN • IXP address space assigned on condition it is not announced to global Internet • RIPE NCC • Requests for PI space handled through existing LIR; no special criteria for IXPs

  5. Proposal • IXPs can apply to APNIC for address space and receive micro assignment, no smaller than /24 • For IXP transit LAN • For Internet Infrastructure Critical Services

  6. Detail One • Address space assigned to IXPs for transit LAN comes out of one reserved block specifically for IXPs • Makes address block well known in region • Technically efficient for ISPs to implement appropriate filters

  7. Detail Two • Address space assigned to the IXP transit LAN must NOT be announced to the global Internet • Accepted best current practice by IXP operators to avoid bandwidth fraud and denial of service attacks • Same as ARIN policy

  8. Detail Three • Hosting Internet Infrastructure Critical Services (IICS) at IXPs • IXP will receive at least one /24 to cover IICS • This address space can be announced to the global Internet • Assignment made on the understanding that the IICS are not on the same logical network as the IXP transit LAN

  9. Detail Four • Address space for IICS comes out of one reserved block for specifically for IICS at IXPs • Makes address block well known in region • Technically efficient for ISPs to implement appropriate filters

  10. Detail Five • APNIC will publicise the IXP minimum assignment size (/24) on their webpages • IXP transit LAN assignments will not be globally visible (more likely regional or local visibility) • IICS address space will be globally visible

  11. Detail Six • IXPs would be APNIC members • Have rights and benefits like other APNIC members • Have obligations like other APNIC members • Be categorised as other APNIC members

  12. Detail Seven • Other IXP address space needs such as for local content services, management network • Address space should come from their membership • This is not Internet critical infrastructure • It does need global routability • Change of address block is minor inconvenience; renumbering an IXP transit LAN can be hugely disruptive

  13. Advantages • IXPs can now become APNIC members • IXPs can now get address space from APNIC • Policy is very similar to ARIN’s No disadvantages!

  14. Internet Infrastructure Critical Services • For this policy, these are defined as: • Root nameservers • gTLD nameservers • ccTLD nameservers • Regional Internet Registries

  15. Implementation • APNIC should implement this policy three months after consensus has been reached • All supporting docs will be updated before this date • Community will be informed before this date

  16. Questions?

More Related