RIPE 35

Amsterdam, 23rd January 2000
IPv6 Working Group


Chair: David Kessens
Scribe: Monica Cortes

A. Administrative stuff
- Appointment of scribe
- Agenda bashing

B. Comments on the Provisional Assignment and Allocation of IPv6
Addresses Policy Document (IPv6 WG - LIR WG) (Mirjam Kuehne)
- Why is the dial-up link treated differently - should
such users get a /48 or a /64?
- Public or private addresses for point-to-point links?
- What constitutes 80% utilisation?

C. Status of 6bone (David Kessens)

D. Issues with filtering of 'IPv6 in IPv4' packets (Thomas Trede)

E. IPv6 Meeting in Berlin (Thomas Trede) &&
IPv6 Forum (Juergen Rauschenbach)

F. Quick summary of EOF morning session (Wilfried Woeber)

G. European developments/initiatives regarding IPv6 (input from
audience)

H. Reports on on-going projects, success & failure stories on IPv6
(input from audience)

I. Input from other working groups

Z. AOB


Action points from RIPE 34: NONE
Action points from RIPE 35: NONE


---------------------

-- A -- Administrative stuff


Scribe was appointed, the agenda was approved without changes


--B -- IPv6 Policy Document Review (ripe-196) (Mirjam Kuehne)


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.



-- D -- Issues with filtering of 'IPv6 in IPv4' packets (Thomas Trede)

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

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.

- Deutsche Telekom outlined the DTAG, ecomerce and end-to-end security

- CSELT had a demo of tunnel-broker. In less than 1 minute one
could have ipv6 connectivity

- IPv6 forum Chair talked about the Forum Mission and membership
(70 members)

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

IPv6 Summit Program:
- Oct 1999 Paris
- Dec 1999 Berlin
NEW:
- 14-15th March 2000 in Colorado, US Summit
- 10th May 2000 in Birmingham, UK IPv6 Event
- Oct 2000 in Tokyo, IPv6 Summit
- 29th Nov - 1st Dec 2000 in Madrid (Spain), IPv6 Summit

IPv6 Forum participates and cooperates in other events:
- 14-16th March 2000 in Paris, on Mobile.ISP
- 15-17th March 2000 in UK, on IP QoS
- 28-29 Oct 1999 in Paris, on IPSec

6INIT (IPv6 INternet IniTiative) is one of the projects of IPv6 Forum.

Some links:
- IPv6 Forum: www.ipv6forum.com
- Berlin Summit: www.berkom.de/ipv6
- US Summit: www.stardust.com/ipv6summit
- sTLA allocations: www.dfn.de/service/ipv6/ipv6aggis.html
- 6INIT: www.6init.org


-- F -- Quick Summary of EOF morning session (Wilfried Woeber)

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



-- G -- European developments / initiatives regarding IPv6 (input from
audience)

Bernard Tuy: We want to deploy an IPv6 native backbone in our
topology. There will be more info in slides in Budapest.


-- H -- Reports on ongoing projects, success & failure stories (input from
audience)

no input


-- I -- Input from other working groups

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.


-- Z -- AOB

none. Session closed