Interim Policy proposal for IPv6 Address Assignment Policy for Internet Exchange Points
Following discussion between the WG-Chairs and the NCC we have the following proposed draft. To enable allocations to be made as soon as possible we are soliciting comments over the next few days but unless there are any issues we would like to start making allocations by the end of next week, ie 7th September 2001. Please send any comments to the LIR-WG list <lir-wg@ripe.net> We propose a joint session to be held at RIPE40 where we can discuss the initial size allocations, information required in the forms and other issues raised by the community after which we will formalise the proposal. Thanks Fearghas EIX-WG Chair -- IPv6 Address Assignment Policy for Internet Exchange Points =========================================================== 1. Abstract ----------- This document describes a policy for Internet Exchange Points (IXPs) under which unique IPv6 address space to be used for the infrastructure of the Internet Exchange Point can be obtained from a Regional Internet Registry (RIR). 2. Background ------------- It has been recognised that there are scenarios in which it is not desirable for IXPs to obtain address space from one of the Internet Service Providers (ISPs) connecting at the IXP. In these cases it is viable to have unique IPv6 address space assigned directly from an RIR. This address space is needed to adress the Exchange fabric. This issue has been brought forward to the RIPE community in May 2000 and has subsequently been discussed at RIPE Meetings and on public RIPE mailing lists. The conclusions of these discussions are described in this document. It is expected that the same policy will be accepted in the ARIN and the APNIC region at which point it will be incorporated in the Global IPv6 Policy document. 3. Definition ------------- An Internet Exchange Point is defined as a physical network infrastructure (layer 2) operated by a single entity with the purpose to facilitate the exchange of Internet traffic between Internet service providers. The number of Internet Service providers connected should at least be three and there must be a clear and open policy for others to join. Addresses needed for other purposes (e.g. additional services provided to the members) should be aquired through other appropriate means ( e.g. an upstream ISP). 4. Policy --------- An IXP that seeks to obtain an IPv6 address assignment by the RIR in its region, needs to submit a request to that RIR. IXPs operating in the RIPE NCC service region should use the 'IPv6 Request Form for Internet Exchange Points' (http://www.ripe.net/ripe/docs/ipv6request-exchangepoint.html). After approval of the request, the RIR will make the assignment. Since the address space does not need to be routable globally and an IXP is expected to only have one subnet, a /64 (64 bits of address space) will be assigned in most cases. In the case the IXP is using multiple fabrics (e.g. unicast separated for multicast), multiple /64s can be assigned to the IXP. IP Address requests can only be handled if the requestor is a Local Internet Registry (LIR) or if the request made through an existing LIR. 5. Other Considerations ----------------------- It should be noted that ISPs usually do not announce address space used on the IXP mesh itself to their peers. That means the address space assigned under this policy is likely not to be routable globally.
Hiya all, Unfortunately, I must respond against the proposal as it stands with use of a /64 allocation. Allocations of /64 for the peering LAN can be obtained already from a separate block (I forget the details - but I think from a US based ISP only block managed by David Huberman). I fail to see therefore what this proposal helps with. This does not solve the problem as I see it, which is how to reliably, and independently of a particular ISP, multihome the infrastructure associated with the exchange point. From which range do the addresses for www.IXP.net or lg.IXP.net or term-serv.IXP.net come from ? For this I propose globaly routable allocations be made, with a size of at least /48. The IXP can then decide whether to use part of that for the exchange LAN, or whether to get a separate /64. Cheers Dave On Fri, 31 Aug 2001, Fearghas McKay wrote: ->Since the address space does not need to be routable globally and an ->IXP is expected to only have one subnet, a /64 (64 bits of address ->space) will be assigned in most cases. -> ->In the case the IXP is using multiple fabrics (e.g. unicast separated ->for multicast), multiple /64s can be assigned to the IXP.
Hi Dave At 3:30 pm +0200 31/8/01, Dave Pratt wrote:
Hiya all,
Unfortunately, I must respond against the proposal as it stands with use of a /64 allocation.
Allocations of /64 for the peering LAN can be obtained already from a separate block (I forget the details - but I think from a US based ISP only block managed by David Huberman). I fail to see therefore what this proposal helps with.
This does not solve the problem as I see it, which is how to reliably, and independently of a particular ISP, multihome the infrastructure associated with the exchange point. From which range do the addresses for www.IXP.net or lg.IXP.net or term-serv.IXP.net come from ?
For this I propose globaly routable allocations be made, with a size of at least /48. The IXP can then decide whether to use part of that for the exchange LAN, or whether to get a separate /64.
The initial allocations will be made with a boundary of /48 to allow for a change to be made if the consensus in Prague is for /48 rather than /64. The address allocation is for infrastructure - so it is likely to filtered, and it will all come from a /35 to ease filter writing. For external facing services the address allocation comes from members/customers rather than this allocation. f
For your information: On Fri, Aug 31, 2001 at 03:30:39PM +0200, Dave Pratt wrote:
Allocations of /64 for the peering LAN can be obtained already from a separate block (I forget the details - but I think from a US based ISP only block managed by David Huberman). I fail to see therefore what this proposal helps with.
Dave is referring to allocations being made by Bill Manning out of a 6bone pTLA that he uses. For example: the Palo Alto Internet Exchange Point in the bay area in california uses addresses provided by Bill. David K. ---
On Fri, 31 Aug 2001, Dave Pratt wrote:
Unfortunately, I must respond against the proposal as it stands with use of a /64 allocation.
If the proposal for the /64 allocation for the IXP mesh is "it" - i.e. this will be the only address space allocated to an IX, period - then I find it hard to be in full agreement with this proposal. The LINX is currently an RIR in it's own right, with a /19 of PA space delegated to it. This is diced up to provide addresses for the IXP meshes at LINX (both Unicast and Multicast), for LINX's own public-facing and member services, and some space is delegated for essential services LINX hosts (such as nic.uk). LINX peers with all it's members, and announces this /19 to them - this means that members have direct, independant connectivity to the LINX services. We also have a handful of transit ISPs (a small subset of members, but over independant media) to fill in the gaps, and make sure we're still online if there is an exchange problem. If v6 addresses for an IXP's member services have to be delegated from an upstream provider, this makes the exchange dependant on that provider. If that provider has problems, or ceases trading, that could have serious impacts on the business continuity of the exchange, for it's member/participant community, and possibly other members of the RIPE community. Please don't say IPv6 address-based multihoming to me. It's not ready for primetime IMHO. What I believe is needed is an allocation for IXP service networks as well as for the IX mesh, which is globally routable. I'd like to propose this alongside the existing proposal we have on the table. Comments? Mike -- Mike Hughes Network Architect London Internet Exchange mike@linx.net http://www.linx.net/ "Only one thing in life is certain: init is Process #1"
What I believe is needed is an allocation for IXP service networks as well as for the IX mesh, which is globally routable. I'd like to propose this alongside the existing proposal we have on the table.
Comments?
I agree with you Mike, I think this is the only way an IXP can show its independence from any one of its members (connected ISPs, carriers or whatever) - Henk
What I believe is needed is an allocation for IXP service networks as well as for the IX mesh, which is globally routable. I'd like to propose this alongside the existing proposal we have on the table. I agree with you Mike, I think this is the only way an IXP can show its independence from any one of its members (connected ISPs, carriers or whatever)
s/ixp/small isp/ i.e. the small isps want to appear independed from their upstream(s). the discussion over this has been going on nigh a decade. so what makes an ixp's business so special they warrant special treatment? randy
On Mon, 3 Sep 2001, Mike Hughes wrote:
The LINX is currently an RIR in it's own right, with a /19 of PA space
Eek! I did, of course, mean LIR :-). Mike -- Mike Hughes Network Architect London Internet Exchange mike@linx.net http://www.linx.net/ "Only one thing in life is certain: init is Process #1"
If the proposal for the /64 allocation for the IXP mesh is "it" - i.e. this will be the only address space allocated to an IX, period - then I find it hard to be in full agreement with this proposal.
it is not. to my knowledge, no one is proposing prohibiting any current allocation policies, merely adding a new one, giving a /64 to peering meshes.
What I believe is needed is an allocation for IXP service networks as well as for the IX mesh, which is globally routable.
there is such a policy, and it applies to anyone, not just ixs. after all, when it comes to the non-ix portion of your business, why should you get special treatment that others do not? what is unusual about an ix is the peering mesh. that warrants special allocation. otherwise, i am sure we all think we have special needs and deserve special treatment. randy
participants (6)
-
Dave Pratt -
David Kessens -
Fearghas McKay -
Henk Steenman -
Mike Hughes -
Randy Bush