To: lir-wg@ripe.net CC: eix-wg@ripe.net Subject: IPv6 for IXPs Date: Tue, 26 Jun 2001 12:22:51 +0200 From: Mirjam Kuehne <mir@ripe.net>

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).

I strongly feel that leaving the term "political reasons" in here (and maybe even allow that to creep into some archive procedural description is setting off a time bomb! The "weakest" term I would accept (instead of requiring _technical_ reasons from the beginning) is "for reasons of stable operations").

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.

I fully agree with that, but at the same time this requiremet weakens the overall reasoning. Just as an observation.

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.

I really like the proposal by Robert.Kiessling: "strongly discouraged to announce the addresses and 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:

What do you intend by saying "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.

For the moment this seems to take care of the situations mentioned during the meeting. However, it might be too fuzzy in general - and too specific as regards the transport mechanism for the packets being exchanged according to the peering agreement. E.g. I might agree with 2 of my students to build an exchange point for IPv6 packets, but we would prefer to use the existing IPv4-based internet as a transport mechanism. Would that be compatible with "(a common layer 2 infrastructure)"? I don't have a better proposal for the moment, unfortunately, but I would like to see (hear :-) people think about those aspects.

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.

Go for the provisions as outlined in the IAB/IESG Recommendation, and if in doubt, assign the bigger block.

5. Other issues raised ----------------------

Requests should only be sent by established LIRs or via an existing LIR.

Please s/should/must/ !!

Reverse delegation would have to be done by the RIR (requested also via an existing LIR)

Agreed. Wilfried. _________________________________:_____________________________________ Wilfried Woeber : e-mail: Woeber@CC.UniVie.ac.at UniVie Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Universitaetsstrasse 7 : Fax: +43 1 4277 - 9 140 A-1010 Vienna, Austria, Europe : RIPE-DB: WW144, PGP keyID 0xF0ACB369 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~