Mirjam presented the open issues and possible points of disagreements of the Allocation of IPv6 addresses document currently in use (ripe-196). It was created in April of last year, it was reviewed by all RIR's regions and the IETF. More discussions on all RIR regions will take place in the near future and the input is welcomed: RIPE meeting this week, next week is the APNIC/APRICOT meeting, ARIN meeting is the first week of April, RIRs will have a retreat the second week of April, where this document will be discussed. New draft document will be available before RIPE 36.

11 allocations have been made so far.

Open Issues:

* section 4.2.3.2 on multi-homing, to be written, currently missing

Mirjam: There is little experience in multimhoming and is still an open issue being discussed at the IETF and EOF. Should the multi-homed have two NLAs assigned each from one provider?

Person1: It is better to assign only one NLA as otherwise he would need to AS numbers and which should he use?

Person2: What is multi homing? one node with several ip addresses or better one address accessed via multiple paths?

David Kessens: Multi-homing is a non solved problem but needs an allocation policy.

Wilfried Woeber: The definition of multi-homing is not clear yet, we should use multi-homing with the current understanding of this term. PI addresses are not valid for IPv6, we don't want to allocate a TLA for all multi-homed sites.

Person1: Then multi-homing can only be done by big organisations

Person3: What is wrong with multiple AS numbers?

Person4: BGP does work, but will stop working if the number of ASN keep growing as now. There will be a shortage of ASN and huge tables. BGP does not scale and won't work.

David Kessens: Aggregation is the only solution for this

Person1: Ok, then let's renumber when a solution is in place

David Kessens: IPv6 design tells you how to do things. The allocation document should not have things different than what the standard defines. It is not politically correct

Mirjam: We should have some text on the document

Person5: Lets add to the text that it is provisional as there are no standards yet

* section 4.2.8 on allocations to NLA registries * section 4.3.1 on assignments to end users

Mirjam: There is no sufficient experience available still, there are no policies and procedures available, input from the community is appreciated.

Bernard Tuy: A proposal would be that they come back when your TLA is allocated an 80% on one level of hierarchy.

Person: Why not indicate that this is a life document and that it can be reviewed in the future?

Daniel Karrenberg: Lets put a date for review.

* definition of "transit-provider" mentioned in the document.

Mirjam: The IETF would not come to a definition of this either and they recommended to remove it altogether from the text. This is our recommendation as well.

WG agrees.

* definition of TLA/NLA/SLA registry

Mirjam: Is a TLA registry the one allocation or assigning TLAs or the one receiving the allocation? The proposed idea is that a TLA registry is the one that allocating or assigning TLA addresses. The same goes for NLA and SLA registries.

WG agrees.

* section 3.2 on Point-to-Point links

Mirjam: should they have public or private addresses? The IETF chair suggests them to be public addresses. Should we remove the paragraph altogether?

David Kessens: I agree with the chair, aggregation is the important thing not conservation. This is not the time to save address space.

Person: (Nods) it is valuable to drop it and have global addresses for debugging purposes

WG agrees.

* section 4.3.1 on Dial-up Assignments

Mirjam: There is controversy about what subnet size should be assigned to a Dial-up customer: a /48 or a /64? There is no enough experience on this; only on NLA allocations or assignments reassigned from the 11 sTLAs. IETF suggests to give a /48.

Person1: What if we just put a magic number, nobody really knows what makes sense. We could indicate that this will be reviewed.

Wilfried Woeber: I agree with the IETF on the Point-to-Point links, but why a /48 instead of a /64 for my dial-up host at home? Mirjam: Should we create a group that investigates this issue?

Wilfried Woeber: Technical aspects should be investigated and then come up with a recommendation or a BCP.

Person2: Every user of mobile phones will get a /48? It is difficult to discuss where to put the boundary for a /48 or /64. We need more experience?

David Kessens: One possibility would be to have a /64 for one single network and a /48 for more than that.

Mirjam: We will have more discussions with the other RIRs and come back with a proposal.

* section 4.2.5 on 80% Utilisation

Mirjam: There is a question on what is meant by 80% Utilisation, is this on only one level of hierarchy or all the address space allocated? Do all the allocations and assignments need to be registered?

Person: 80% is a xxx million customers. Will that ever be full?

Daniel Karrenberg: This was a safeguard for people who wanted to be assured that they could grow and have more addresses in a future point in time.

Person1: How to use the NLA field? One can imagine all types of possibilities from the bad two extremes: - NLA1 has 1 bit which means 2 ISPs and NLA2 field 8bits or 256 end sites or - NLA1 has 8bits or 256 possible ISPs and NLA2 field 1 bit so 2 end sites each

David Kessens: IETF WG chairs say that a /29 is already a slow start, a /35 is not much. There is a fear that conservation is the main argument and not aggregation

Mirjam: Aggregation is the key of the document, we allocate a /35 but we reserve the rest of the /29. We will give more space depending on the usage rate. If the usage rate is high the next allocation will be the full /29. If it is slow only a few more bits will be given.

Wilfried Woeber: We need more real life experience before changing the document

David Kessens: What expiry date should the document have?

After WG input agreed upon: 12 months

Bernard Tuy: I would like to say to the RIPE NCC: keep it going! It is very useful to have this discussions also months after the first document was drafted.

COFFEE BREAK

-- C -- Status of the 6bone (David Kessens)

Presentation can be found at: http://www.kessens.com/~david/presentations/

In the last 4 months the 6bone registry as seen a 15% growth. The number of countries that have joined the 6bone is stable now. The number of queries have decreased about 20% to 2400 queries a day. This is because a heavy user of the database is now running a mirror of his own. The number of updates is stable as well, about 8 update a day.

Presentation can be found at: http://www.tu-darmstadt.de/hrz/staff/data/trede/RIPE35-trede-ipv6conf.ppt

Thomas asked the audience if anyone had experienced any type of filtering of IPv6 traffic by filtering IPv6 in IPv4 packets. This had been seen by some people although it was not confirmed.

Wilfried Woeber: Is it general tunnel filtering or targeted filtering? Thomas Trede: Only one site experienced this, and it is not clear what type of filtering it is. It is good to see that no-one else in the audience had experience something similar.

-- E1 -- IPv6 Meeting in Berlin (Thomas Trede)

This is the second IPv6 forum meeting and was held in Berlin. There were many talks so only the highlights of the talks will be presented here. More about this meeting can be found in http://www.berkom.de/ipv6

Presentations:

- NTT plans a world wide IPv6 native network. NTT won't charge for access to their IPv6 network from USA or EU.

- NATO announced in 1999 the principal decision to go for IPv6 The German Navy have an IPv6 Application with QoS for the Navy.

- Vendors & ISPs are moving forward: - Sun, Compaq (Digital) will have IPv6 in their new OS version - Routers: Telebit has IPv6, Cisco say: 'by the 2nd half of 2000', their IOS has still bugs in their current version - Microsoft: Windows 2000 won't have IPv6 - Kame project has been prolonged until 3/2002

- 3Com had a presentation about 6over4. Support fro IPv6 in the USA is increasing

Conclusions:

- The implementations are stable and ready, in the router market Cisco is the mayor obstacle.

- More engagement of ISPs is needed. More connectivity tests need to be performed, tests on Exchange Points, and customer connectivity.

- Are we ready? There is the chicken and egg problem: Hardware or software, everyone points to the other-one.

-- E2 -- IPv6 Forum (Juergen Rauschenbach)

Presentation can be found at: http://www.kessens.com/~david/presentations/

The Forum's Mission is to promote IPv6 by improving the market and user awareness of IPv6, creating a quality and secure Internet. It promotes new IPv6-based applications and solutions, promotes the knowledge and experience sharing among members, resolve issues that create barriers to IPv6 deployment.

There are 78 members per 17th February: 29 in North America, 36 in Europe, 13 in Asia/Pacific. There are 12 research organisations and the biggest group are network suppliers, though bit telco's and ISPs are also present.

The IPv6 Forum consists of a Board of 8 members, a Promotion Group (15 Marketers) and a Deployment Group (34 Experts). In this last group is the IPv6 Technical Directorate that is responsible for the technical part of the Forum, gives direction and advice to the Forum and the industry and makes the link between IETF and the industry. The Promotion Group has IPv6 education and awareness programs, organises global IPv6 Summit/Conferences, has a Strategic Alliance Program and Strategic Alliances with the UMTS Forum, the GSM Association, Stardust.com, GIPF (France), ETSI (EU) and 3GPP.

There were two presentations one from Stuart and the other from Woeber. Both presentations were largely in agreement about the results and future way to go. There is still work needed on IPv6 routing and DNS infrastructure of IPv6 transport.

Person: We found two mayor problems on our setup. One is finding the bit boundaries and having new procedures, and the second is that we found problems in our accounting and billing infrastructure.

David Kessens: I will try to organise an IPv6 tutorial, something more hands-on

David Kessens: EIX working group was talking about allocations of TLA to exchange points and could not take any resolution on this, so this point has come back to the IPv6 WG.

Mirjam Kuehne: The IX points don't think it is a good idea to act as an NLA registry for their members. The RFC has this possibility as a concept, but the EIX did not see it as feasible at this point in time.

Christian Panigl: The IX would have to give transit to the transit points of members. This is a contradiction of the neutrality of an IX point.

Mirjam Kuehne: The IETF worked on the possibility of the existence of a different type of IX point.

Bernard Tuy: Where should these policy discussions take place: LIR WG, IPv6 WG the EIX WG? How can we have better interactions?

David Kessens: For this reason we hold a joint WG session with LIR WG in the first half.

Wilfried Woeber: In order to tackle the problem, we should set up an editorial commity that puts comments and suggestions together and forward the document to the mailing list or move the IP address issues to the LIR mailing list to focus the discussions.

David Kessens: It is an LIR issue, but IPv6 is still experimental and should be kept in this WG.

Bernard Tuy: Let's keep it like today in shared sessions.

Mirjam Kuehne: After the meetings with the other RIRs, we will submit the document to the IPv6 WG and LIR WG. In the IPv6 WG the people are more involved in these issues.

The RIPE NCC uses cookies. Some of these cookies may have been set already. More information about our cookies can be found in our privacy policy. You can accept our cookies either by clicking here or by continuing to use the site.