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.
On Fri, 31 Aug 2001, Fearghas McKay wrote:
Please send any comments to the LIR-WG list <lir-wg@ripe.net>
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.
Care to explain how traceroute through these IX's is supposed to work, if the node performing traceroute, ping, or whatever, is not a small-scale customer (ie. default route) of the IX participants? As far as I can see, this is impossible. Moreover, as the scope of these addresses is global, the routers responding to ping, traceroute etc. cannot select a better source address (e.g. a truly global address assigned to loopback device) for the response packets. The only way to deal with this, as far as I can see, is just assign like /35's or equivalent to IX's too (it's not like there are thousands of them!), or make the assignments from a special block which MUST be exempted from BGP DFZ aggregation filtering rules. Or, you could define this allocation policy only for a specific kind of exchange points (client organizations of the IX participants must not participate in DFZ so that there wouldn't be aggregation filtering; often this could mean only bi-lateral peering of "small-scale" DFZ, or smaller, organizations). Practically, I suppose, this excludes IX's where there are upstream/long-haul (e.g. trans-atlantic) operators present. Practically, the address assignment seems equivalent of adding no-export BGP community to some /35 prefix, using it for point-to-point links and announcing it everywhere. With some IX configurations, the results might not be pretty for tracerouters. I guess the easiest approach here might be to clarify (e.g. by giving examples) which kind of IX's should/should not adopt this approach based on the routability arguments. (if this is not done, the IX's that can't adopt this approach might be given cold treatment when they apply for another kind of addresses, and be pointed out that there is already a scheme for IX's) -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords
Hi, On Fri, Aug 31, 2001 at 03:58:04PM +0300, Pekka Savola wrote:
On Fri, 31 Aug 2001, Fearghas McKay wrote:
Please send any comments to the LIR-WG list <lir-wg@ripe.net>
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.
Care to explain how traceroute through these IX's is supposed to work, if the node performing traceroute, ping, or whatever, is not a small-scale customer (ie. default route) of the IX participants?
For a traceroute *through* the IX you don't need the route to that /64. It might get filtered if you do RPF filtering (but multihomed customers usually don't, because it doesn't work), but reachability of the hosts *behind* the IX is not a problem. Whether it's desireable to be able to traceroute *to* an IX address is debateable (but that's not different from today), this is what wouldn't work. Gert Doering -- NetMaster -- SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
On Fri, 31 Aug 2001, Gert Doering wrote:
On Fri, Aug 31, 2001 at 03:58:04PM +0300, Pekka Savola wrote:
Care to explain how traceroute through these IX's is supposed to work, if the node performing traceroute, ping, or whatever, is not a small-scale customer (ie. default route) of the IX participants?
For a traceroute *through* the IX you don't need the route to that /64. It might get filtered if you do RPF filtering (but multihomed customers usually don't, because it doesn't work), but reachability of the hosts *behind* the IX is not a problem.
RPF is an additional issue, granted, but not the point here. Traceroute will skip a hop or two, ie. those p-t-p links where these internal addresses are used; these might be crucial when debugging or tracing where the traffic goes. This might make (depending on the topology) a 15 second wait for the magic '* * *' combination. After and before these, it will continue in a normal fashion. But boy, would this be annoying..
Whether it's desireable to be able to traceroute *to* an IX address is debateable (but that's not different from today), this is what wouldn't work.
Different from today how? Not necessarily. One can use global addresses where you can traceroute to without problems. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords
Hi, On Fri, Aug 31, 2001 at 04:17:19PM +0300, Pekka Savola wrote:
It might get filtered if you do RPF filtering (but multihomed customers usually don't, because it doesn't work), but reachability of the hosts *behind* the IX is not a problem.
RPF is an additional issue, granted, but not the point here.
Traceroute will skip a hop or two, ie. those p-t-p links where these internal addresses are used; these might be crucial when debugging or tracing where the traffic goes.
No, it won't. Unless you're RPF-filtering, you won't be able to "ping" those IPs, but traceroute will show them just fine, including DNS.
This might make (depending on the topology) a 15 second wait for the magic '* * *' combination.
No. As with a traceroute showing RFC1918 IPs today - unless you explicitely filter those packets, the non-reachability won't harm traceroute. [..]
Whether it's desireable to be able to traceroute *to* an IX address is debateable (but that's not different from today), this is what wouldn't work.
Different from today how? Not necessarily. One can use global addresses where you can traceroute to without problems.
Quite a number of IXPs do not want their transit network to be announced into the global table. So that's what you will have with IPv6 as well. If an IXP wants to use globally routed addresses, he can always become a LIR and apply for a /35. What we're talking about is for those IXPs that need a /64 and do not want to see / need to have it routed globally. Gert Doering -- NetMaster -- SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
Pekka Savola wrote:
On Fri, 31 Aug 2001, Gert Doering wrote:
On Fri, Aug 31, 2001 at 03:58:04PM +0300, Pekka Savola wrote:
Care to explain how traceroute through these IX's is supposed to work, if the node performing traceroute, ping, or whatever, is not a small-scale customer (ie. default route) of the IX participants?
For a traceroute *through* the IX you don't need the route to that /64. It might get filtered if you do RPF filtering (but multihomed customers usually don't, because it doesn't work), but reachability of the hosts *behind* the IX is not a problem.
RPF is an additional issue, granted, but not the point here.
Traceroute will skip a hop or two, ie. those p-t-p links where these internal addresses are used; these might be crucial when debugging or tracing where the traffic goes.
This might make (depending on the topology) a 15 second wait for the magic '* * *' combination.
After and before these, it will continue in a normal fashion. But boy, would this be annoying..
That depends on how your particular traceroute works. The common approach is to send packets (typically UDP to high-numbered ports) to the _destination_ address with increasing TTLs and look for the ICMP TTL Exceeded message to come back from each intermediate hop -- no traceroute packets are addressed _to_ the intermediate routers. So, unless you're explicitly filtering packets sourced from unrouted address space (e.g. RPF), you'll still get a useful(?) traceroute output. James
For a traceroute *through* the IX you don't need the route to that /64. It might get filtered if you do RPF filtering (but multihomed customers usually don't, because it doesn't work), [...]
The less-strict "reachable-via-any" (I forget its exact syntax, but should be usable by multihomed sites) unicast RPF checking will however also break the traceroute if the /64 isn't announced as reachable in the DFZ. Regards, - Håvard
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. Care to explain how traceroute through these IX's is supposed to work, if the node performing traceroute, ping, or whatever, is not a small-scale customer (ie. default route) of the IX participants?
works quite well, actually. each participating isp routes the mesh in their internal and customer networks, just does not hand it to peers. this is quite common in v4 exchanges. see my nanog presentation in feb '97. randy
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 (10)
-
Dave Pratt -
David Kessens -
Fearghas McKay -
Gert Doering -
Havard Eidnes -
Henk Steenman -
James Aldridge -
Mike Hughes -
Pekka Savola -
Randy Bush