Dear all, After the active discussion regarding IPv6 address for Internet Exchange Points (IXPs), we now need to come to a conclusion. I have reviewed the discussion again and will try to summarise it (quite a challenge :-). Many issues were raised, but so far no clear consensus was reached. Please bare with me if I have not included all opinions and comments or if some submissions are not summarised accurately. However, I hope that this summary will spark some further discussions and hopefully a conslusion at the end. I cc the eix-wg mailing list here and would like to explicitely encourage IXP operators to actively participate in this discussion. Kind Regards, Mirjam Kuehne RIPE NCC ---------- The following questions were raised during the discussion: 1. Is a special policy needed for IXPS (and following from this possibly also for other 'special purposes'? 2. What is the intended use of the addresses at the IXPs? 3. How is an IXP defined? 4. What size should be assigned? 1. special policy needed? ------------------------- Many participants believed that a policy for IXPs is needed, because they usually do not have an upstream provider and also do not want to use addresses from one of their members (for political rather than technical reasons). Some participants however felt that no special policy is needed for IXPs. They should either be treated as an end-user network or should be able to get a 'normal' (currently a /35) IPv6 allocation from the RIRs. 2. intended use of the addresses? ---------------------------------- Special policy would only be needed for addresses needed for the Exchange Point medium itself (usually a layer-2 network). Addresses needed for other purposes (e.g. additional services provided to the members) should be assigned by upstream ISPs. It was also discussed if the addresses should actually be announced. It was felt that this is not really necessary, but that some IXPs do it anyway. There was no conclusion if this should be part of the policy (e.g. the micro-allocation policy implemented in the ARIN region does require that the prefix is not announced). One option would be to warn the IXP that these addresses are likely not to be globally routable. 3. definition of an IXP ----------------------- It was generally felt that it is difficult to define an IXP, but that the following refined definition could be used as a starting point: Three or more ASes and thee or more separate entities attached to a LAN (a common layer 2 infrastructure) for the purpose of peering and more are welcome to join. 4. assignment size? ------------------- Some participants felt that a /64 would be appropriate if the IXP would consist of only one subnet. In all other cases a /48 should be assigned (this would be consistent with the IESG/IAB recommendation). Others felt that the address size should not be pre-defined, but should be based on need and discussed on a case-by-case basis between the requestor and the RIR. 5. Other issues raised ---------------------- Requests should only be sent by established LIRs or via an existing LIR. Reverse delegation would have to be done by the RIR (requested also via an existing LIR)
Mirjam, thank you for the summary. My EUR 0.02 follow. Mirjam Kuehne writes:
1. Is a special policy needed for IXPS (and following from this possibly also for other 'special purposes'? 2. What is the intended use of the addresses at the IXPs? 3. How is an IXP defined? 4. What size should be assigned?
1. special policy needed?
Yes. Most exchange points are supposed to be neutral, so address space should be available to support that. This leaves the choice to the IXP whether to use neutral, non-routable or LIR-bound routable space, or get an IPv6 allocation themselves.
2. intended use of the addresses? ----------------------------------
Special policy would only be needed for addresses needed for the Exchange Point medium itself (usually a layer-2 network).
Ack.
One option would be to warn the IXP that these addresses are likely not to be globally routable.
I would make the wording for this as strong as possible and thus prefer "may not be globally announced", but that might not be possible since this is hard to define and RIPE's authority over this is questionable. So maybe something like "strongly discouraged to announce the addresses and likely not to be globally routable"?
3. definition of an IXP -----------------------
Three or more ASes and thee or more separate entities attached to a LAN (a common layer 2 infrastructure) for the purpose of peering and more are welcome to join.
Fine. I don't think we should make this too strict, since there's enough /48 blocks available even for some "fake" IXPs.
4. assignment size? -------------------
Some participants felt that a /64 would be appropriate if the IXP would consist of only one subnet. In all other cases a /48 should be assigned (this would be consistent with the IESG/IAB recommendation).
A /48 should also be assigned if the IXP only plans to expand to multiple networks. Apart from that I think we should indeed stick to standard assignment sizes as suggested. Robert
One option would be to warn the IXP that these addresses are likely not to be globally routable. I would make the wording for this as strong as possible and thus prefer "may not be globally announced", but that might not be possible since this is hard to define and RIPE's authority over this is questionable. So maybe something like "strongly discouraged to announce the addresses and likely not to be globally routable"?
and the level of indirection, it's the isps not the exchange which announces, makes it hard for the ix to act on this suggested policy (with which i agree, as well as your other points, fwiw) randy
Dear Mirjam, I have several thinks to be discussed.
2. intended use of the addresses? ----------------------------------
Special policy would only be needed for addresses needed for the Exchange Point medium itself (usually a layer-2 network). Addresses needed for other purposes (e.g. additional services provided to the members) should be assigned by upstream ISPs.
I am not sure, if all of the exchanges are pure l-2. It is OK for classic european "ethernet switch" IXPs, but in other model it should be different. Some IXPs are not only infrastructure for interconnection and they sometimes offer some public services. I cannot determine all of them, but in example: NTP, traffic statistics, root DNS servers and some other (hope people from LINX or NETNOD should find some others).
It was also discussed if the addresses should actually be announced. It was felt that this is not really necessary, but that some IXPs do it anyway. There was no conclusion if this should be part of the policy (e.g. the micro-allocation policy implemented in the ARIN region does require that the prefix is not announced).
You have to announce addresses for "public" services.
3. definition of an IXP -----------------------
It was generally felt that it is difficult to define an IXP, but that the following refined definition could be used as a starting point:
Three or more ASes and thee or more separate entities attached to a LAN (a common layer 2 infrastructure) for the purpose of peering and more are welcome to join.
What is the goal of this definition? It is to restrict other subjects to use these addresses? If yes, there are also some transit ISPs POPs which fit your definition. We discussed definition of IXP on some forums, but we didn't get right definition. Definition is different on basis of your goal :-)
5. Other issues raised ---------------------- Requests should only be sent by established LIRs or via an existing LIR.
Reverse delegation would have to be done by the RIR (requested also via an existing LIR)
Hm ... So IXP have to establish it's own LIR or borrow this service from it's members ? :-) MK
Some IXPs are not only infrastructure for interconnection and they sometimes offer some public services. I cannot determine all of them, but in example: NTP, traffic statistics, root DNS servers and some other (hope people from LINX or NETNOD should find some others).
i thought we had this discussion. those services should not be in the exchange mesh address space.
It was also discussed if the addresses should actually be announced. It was felt that this is not really necessary, but that some IXPs do it anyway. There was no conclusion if this should be part of the policy (e.g. the micro-allocation policy implemented in the ARIN region does require that the prefix is not announced). You have to announce addresses for "public" services.
see above randy
Some IXPs are not only infrastructure for interconnection and they sometimes offer some public services. I cannot determine all of them, but in example: NTP, traffic statistics, root DNS servers and some other (hope people from LINX or NETNOD should find some others).
i thought we had this discussion. those services should not be in the exchange mesh address space.
Umm ... So IXP's have to have two address blocks for it's infrastructure (one for interconnection infrastructure and one for public services) ? If I am right, please write exactly this important information to the document. MK
Umm ... So IXP's have to have two address blocks for it's infrastructure (one for interconnection infrastructure and one for public services) ?
If I am right, please write exactly this important information to the document.
a plan for allocation of ix mesh space should not prescribe how ix operators do other things. that starts a long and slippery slope. randy
Michal Krsek writes:
Some IXPs are not only infrastructure for interconnection and they sometimes offer some public services. I cannot determine all of them, but in example: NTP, traffic statistics, root DNS servers and some other (hope people from LINX or NETNOD should find some others).
I think this was addressed in the discussion, with the solution to get normal IPv6 space from the usual sources for thoses services. For example the K root nameserver does not sit on the LINX exchange network itself, but in a very different netblock, and this model could be applied to IPv6, too. If an IXP insists on putting those services on the same net, they can of course do so if they get routable IPv6 space for it, through standard procedures. Use of those addresses for IXPs is in no way forced.
3. definition of an IXP -----------------------
Three or more ASes and thee or more separate entities attached to a LAN (a common layer 2 infrastructure) for the purpose of peering and more are welcome to join.
What is the goal of this definition? It is to restrict other subjects to use these addresses?
I'd pragmatically say the need came up for addresses for this usage, so it had to be defined somehow, in order not to create a source for arbitrary non-routable globally-unique IPv6 addresses.
If yes, there are also some transit ISPs POPs which fit your definition. We discussed definition of IXP on some forums, but we didn't get right definition. Definition is different on basis of your goal :-)
Well, it can be discussed endlessly what the "right" definition is. I wouldn't mind if some "transit ISPs POPs" fit this definition if people peer there (as opposed to just getting transit). So they next question will be what "peering" is, but please, no ...
Hm ... So IXP have to establish it's own LIR or borrow this service from it's members ? :-)
Yes, why not? It's not externally visible through which LIR the request was made. Robert
Robert Kiessling wrote:
Michal Krsek writes:
Some IXPs are not only infrastructure for interconnection and they sometimes offer some public services. I cannot determine all of them, but in example: NTP, traffic statistics, root DNS servers and some other (hope people from LINX or NETNOD should find some others).
I think this was addressed in the discussion,
Apologies, but I am afraid I missed this (local-ir ?) discussion. Could someone please recap the arguments here, because I do not understand why this is necessary. Our requirements for reachability and neutrality of our "value-added" services are just as strong as for the IXP mesh itself.
If an IXP insists on putting those services on the same net, they can of course do so if they get routable IPv6 space for it, through standard procedures. Use of those addresses for IXPs is in no way forced.
This is not true. Under the current allocation procedures it is not possible for properly neutral IXPs, even if they are a local-ir, to get an IPv6 allocation, so we have no alternative to these types of addresses. The fact we've been trying to get such an allocation and have been waiting six months (and LINX even longer) for same is the reason for this whole discussion thread in the first place. This means the policy for IPv6 allocation is efectively more stringent than for IPv4. I am at a loss to understand why this is the case - surely the point of allocation guidelines is to (a) protect utilisation of remaining address space, and (b) minimise the number of entries in router tables. For (a), we have a whole lot more address space available in v6 than v4, and for (b), the total number of IXPs is at least two orders of magnitude less than for ISPs, i.e. marginal. So why do we need more restrictive policies ?
with the solution to get normal IPv6 space from the usual sources for thoses services. For example the K root nameserver does not sit on the LINX exchange network itself, but in a very different netblock, and this model could be applied to IPv6, too.
Indeed, if the argument as above is that the mesh parts of IXPs need to have seperate alllocations (and if this is the policy, then don't stop me getting *both* in my own right), this increases (b) the number of routing table entries. Our ideal requirement is to have a single (say /48) allocation in which we would operate a number of (say /64) IXPs, only one prefix total. Keith http://www.xchangepoint.net/contact/keith/
This is not true. Under the current allocation procedures it is not possible for properly neutral IXPs, even if they are a local-ir, to get an IPv6 allocation, so we have no alternative to these types of addresses. The fact we've been trying to get such an allocation and have been waiting six months (and LINX even longer) for same is the reason for this whole discussion thread in the first place.
This means the policy for IPv6 allocation is efectively more stringent than for IPv4.
Agreed.
I am at a loss to understand why this is the case - surely the point of allocation guidelines is to (a) protect utilisation of remaining address space, and (b) minimise the number of entries in router tables.
For (a), we have a whole lot more address space available in v6 than v4,
The current allocation scheme hands out /35 prefixes (RIPE-196) ... |-3|--13-|--13-|-6-|--13-|--16--|------64 bits-----| +--+-----+-----+---+-----+------+------------------+ |FP|-TLA-|-sub-|Res|-NLA-|--SLA-|---Interface ID---| |--|-ID--|-TLA-|---|--ID-|--ID--|------------------| +--+-----+-----+---+-----+------+------------------+ There are 2^29 (~500 million) of these /35s available which is 2^13 (~8000) times larger than existing AS number space. We don't have to worry about running out of /35s but do need to worry about them filling up the routing tables.
and for (b), the total number of IXPs is at least two orders of magnitude less than for ISPs, i.e. marginal.
A 1% increase in number of /35 prefixes (routes) is not a problem. Treating IXPs specially and giving them /35s would be most convenient for IXPs.
So why do we need more restrictive policies ?
To stop all the multihomed customers getting /35s and filling the routing tables. AIUI supporting multiple IPv6 prefixes on hosts has not been completely solved and I suspect that it will always be easier and more prestigious for multihomed customers to have a /35 rather than a handful of /48s. If we treat IXPs as a special case we have to be careful not to let multihomed customers qualify. Defining "IXP" in such as way as to include what we commonly understand by the term and not include multihomed customers is hard to do :-( Chris.
In article <LOEJJGOHNFDKDOAECBAPIEIMCHAA.michal.krsek@cesnet.cz>, Michal Krsek <michal.krsek@cesnet.cz> writes
Some IXPs are not only infrastructure for interconnection and they sometimes offer some public services. I cannot determine all of them, but in example: NTP, traffic statistics, root DNS servers and some other (hope people from LINX or NETNOD should find some others).
It was also discussed if the addresses should actually be announced. It was felt that this is not really necessary, but that some IXPs do it anyway. There was no conclusion if this should be part of the policy (e.g. the micro-allocation policy implemented in the ARIN region does require that the prefix is not announced).
You have to announce addresses for "public" services.
Public services offered by the LINX include all those listed above, plus our "marketing" website. (Internet companies need websites too!) We also run several websites and mailing lists for "good causes", like the Internet User Privacy Forum and Internet Crime Forum. -- Roland Perry | tel: +44 1733 207705 | roland@linx.org Director of Public Policy | fax: +44 1733 207729 | http://www.linx.net London Internet Exchange | mbl: +44 7050 604080 | /contact/roland
Public services offered by the LINX include all those listed above, plus our "marketing" website. (Internet companies need websites too!) We also run several websites and mailing lists for "good causes", like the Internet User Privacy Forum and Internet Crime Forum.
congratulations! but are these run in the address space of the peering mesh? randy
In article <E15Ewpb-000NC0-00@rip.psg.com>, Randy Bush <randy@psg.com> writes
congratulations! but are these run in the address space of the peering mesh?
No, but if the two address spaces were contiguous it could form one allocation. You are presumably arguing that two separate allocations would be more suitable. -- Roland Perry | tel: +44 1733 207705 | roland@linx.org Director of Public Policy | fax: +44 1733 207729 | http://www.linx.net London Internet Exchange | mbl: +44 7050 604080 | /contact/roland
Roland Perry writes:
In article <E15Ewpb-000NC0-00@rip.psg.com>, Randy Bush <randy@psg.com> writes
congratulations! but are these run in the address space of the peering mesh?
No, but if the two address spaces were contiguous it could form one allocation. You are presumably arguing that two separate allocations would be more suitable.
I don't remember that this argument was brought forward. It's entirely your choice what kind of addresses you use. If you have a suitable block, you can of course tkat that. But if you don't, the proposal provides a possible solution. RIPE does not discuss or recommend the different options. They just provide non-routable globally unique IPv6 assignments for IXPs which want them. Robert
Mirjam, Even though there has been some discussion on the list already, I wanted to comment on your initial mail which summarised questions raised - as you know I am keen to resolve this working for an IXP who`d very much like to have an IPv6 allocation! Two comments I`d like to discuss are: "One option would be to warn the IXP that these addresses are likely not to be globally routable". Can we not move towards the current ipv4 methodology of assignment, allowing the LIR to assign its addresses on the basis it has proved its worth during the request for address space process? "Addresses needed for other purposes (e.g. additional services provided to the members) should be assigned by upstream ISPs". Again, as an IXP, we`d welcome a more integrated approach to v6 assignment rather than the separation of peering lans and `other purposes` (I appreciate I wasn't at the meeting and these points may have already been discussed). Regards, Steve.
congratulations! but are these run in the address space of the peering mesh? No, but if the two address spaces were contiguous it could form one allocation. You are presumably arguing that two separate allocations would be more suitable.
i was trying to point out that it is irrelevant to the discussion. randy
In article <E15FHSz-0006Sk-00@rip.psg.com>, Randy Bush <randy@psg.com> writes
congratulations! but are these run in the address space of the peering mesh? No, but if the two address spaces were contiguous it could form one allocation. You are presumably arguing that two separate allocations would be more suitable.
i was trying to point out that it is irrelevant to the discussion.
Steve Walker seems to have just asked for the same thing as I was. If that's so, we seem to be getting a consensus between London-based IXPs... -- Roland Perry | tel: +44 1733 207705 | roland@linx.org Director of Public Policy | fax: +44 1733 207729 | http://www.linx.net London Internet Exchange | mbl: +44 7050 604080 | /contact/roland
On Tue, 26 Jun 2001, Mirjam Kuehne wrote:
3. How is an IXP defined?
(...)
3. definition of an IXP -----------------------
It was generally felt that it is difficult to define an IXP, but that the following refined definition could be used as a starting point:
Three or more ASes and thee or more separate entities attached to a LAN (a common layer 2 infrastructure) for the purpose of peering and more are welcome to join.
My way of writing it, would be: "Three or more ASes owned/managed by 3 or more separate entities attached to a common layer 2 infrastructure, for the purpose of peering." - I dont see an IXP necessarily as a LAN. An IXP can be distributed geographically, so the IXP infrastructure can really be called a WAN. - The same way we dont refer what kind of peering is done (BGPv4, normally) i think we shouldnt limit the definition introducing the "more are welcome to join" part... Of course i want all IXPs to grow (regarding the number of peers) and especially the one i manage :-), but i feel this "welcome call" is more just another "political" issue. Thanks, ./Carlos "Networking is fun!" ------------------- <cfriacas@fccn.pt>, CMF8-RIPE, Wide Area Network WorkGroup http://www.fccn.pt F.C.C.N. - Fundacao para a Computacao Cientifica Nacional fax: +351 218472167
3. definition of an IXP -----------------------
It was generally felt that it is difficult to define an IXP, but that the following refined definition could be used as a starting point:
Three or more ASes and thee or more separate entities attached to a LAN (a common layer 2 infrastructure) for the purpose of peering and more are welcome to join.
A physical network infrastructure 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. - Henk
participants (10)
-
Carlos Friacas -
Chris -
Henk Steenman -
Keith Mitchell -
Michal Krsek -
Mirjam Kuehne -
Randy Bush -
Robert Kiessling -
Roland Perry -
Steve Walker