RIPE 44

• content to the Chair of the working group.
• format to [email protected].

Minutes of the LIR Working Group session at RIPE 44.

Meeting: RIPE 44 LIR WG Session
Date: 29 January 2003
Chair: Hans Peter Holen (HPH)
Co-Chair: Denesh Bhabuta (DB)
Scribe: Laura Cobley

In addition to these minutes a full recording of the pre and post coffee break LIR WG sessions are available from:

rtsp://webcast.ripe.net/Archive/lir-1.rm and
rtsp://webcast.ripe.net/Archive/lir-2.rm

Agenda:
http://www.ripe.net/ripe/meetings/archive/ripe-44/agendas/lir.html

A. Update
B. Agenda Bashing
C. RIPE 43 mins + Actions
D. RS Report - Leo Vegoda
E. Address Council Report - Mark McFadden
F. Election of new LIR WG chairs
G. LIR Portal - Leo Vegoda & Manuel Valente
H. Mailing List AUP
I. Working Group name
J. PI Address Policy
K. IPv6 Policy experiences
L. IP Addressing policy for always-on (residential broadband) revisited
M. Summary of ALLOCATED and ASSIGNED variants for v4 and v6 - Wilfried Woeber
N. EGLOP Multicast Policy Discussion - Marc-Olivier Mehu

8<---------- cut ----------->8

A. Welcome - Hans Peter Holen

Mailing list: [email protected]
Archive
Joining

Note: As this meeting will be webcast, please use the microphones and remember to state your name and affiliation.

8<---------- cut ----------->8

B. No amendments to agenda.

8<---------- cut ----------->8

C. RIPE 43 minutes were posted on the mailing list - no comments were posted. No additional comments from audience.

Previous actions:

35.4 Implementation of PGP for HM - Work In Process (WIP) ERX - longterm WIP
38.2 Changes to request form - WIP
38.6 Discuss PI policy - to be discussed today
Discuss /22 requirement for 1st Allocation - OPEN
Last day today for comments on sub-allocation policy
43.1 Reduce wait queue - Achieved (congratulations)
43.3 Experimental Policy draft - DONE
43.5 Present ASN stats - (WIP)
43.6 Nomination and election of chairs - to be discussed today
43.7 Update ASN policy - Done

8<---------- cut ----------->8

D. Registration Services Report - Leo Vegoda
http://www.ripe.net/ripe/meetings/archive/ripe-44/presentations/ripe44-lir-rs/page1.htm

Comments:

Wilfried Woeber (ACOnet) (WW):
There are a few points to be discussed. Routing Registry training is seemingly only open to LIR contacts, who are sometimes only administrative. Can the more technical people participate with approval from an LIR contact? There was one incident where a registered contact tried to enrol a colleague and couldn't. The request was refused as he was not authorised. What is the reason?

Leo Vegoda (RIPE NCC) (LV):
We are offering training courses as a service to LIRs, and not directly to the public. As a workaround, you could use the LIR Portal to add a contact, register for the course, and then delete the contact afterwards. Otherwise, have the LIR contact send a mail to confirm the attendance of the colleague. The problem exists because the signup process was designed for LIR courses only. We have adapted it for the two new courses - but need to make more changes. We will be trying to make things easier all round. In the meantime, workarounds appear to be the only way. However, it might be possible to add a sign-up feature in the LIR Portal. This can be investigated.

WW: The courses shouldn't be limited to LIR contacts.

LV: Of course not, we expect the technical people to attend.

WW. Agrees with delaying discussion regarding status values. However, is currently confused over which have been agreed upon, and which are still open for discussion. Request directed at community rather than NCC.

LV: We want input from the community. Our aim is for people to be able to get information from one single document in order to make things easier.

WW: Issue with ASN transfer for ERX project. Wants to know if he is the only LIR which still has open tickets (no response).

LV: Can be discussed privately.

Wolfgang Tremmel (VIA NET.WORKS):
Suggestion to include/highlight updates in documents so we can easily identify changes?

LV: Nick agrees, we will consider this.

Bernard Tuy (RENATER) (BT):
Are you providing reverse delegation for the /48s issued to organisations (200)?

LV: No, only for IXPs. It's not a form of PI for IPv6.

8<---------- cut ----------->8

E. Address Council Report - Mark McFadden
http://www.ripe.net/ripe/meetings/archive/ripe-44/presentations/ripe44-lir-aso/

ASO Policy Mailing List:
http://aso.icann.org/wilma-bin/wilma/aso-policy#browse

No comments were made

8<---------- cut ----------->8

F. Election of new LIR-WG chairs

HPH: There is currently one chair and two co-chairs. DB is the only remaining co-chair since James left to work at the RIPE NCC.

DB (Aexiomus Ltd.): Is there a need for a second chair? Should I be re-elected? There are three contributions:

- HPH (to continue)
- Gert Doering (GD) (nominated by Kurt Lindqvist)
- Andrea Borgato (AB) (nominated himself)

GD (SpaceNet): Can't help getting involved in discussions and thinks he should do it in a more official capacity.

AB (I.NET S.p.A.): Useful to co-operate in policy discussion and therefore nominates himself.

HPH (Tiscali): Has been chair for a few years (since 1998). Is also on Address Council. Interested in continuing. Wants to make a couple of points:

- Denesh will be standing down this year and is therefore not standing for re-election.
- Are there any other nominations for chair? (no response) So, how should we proceed? How should the work be distributed?

GD: I've also been asked to co-ordinate between LIR-WG and IPv6-WG.

HPH: Asked if anyone disagreed with the nominations. No disagreements and so all three nominees were approved by acclamation.

- COFFEE BREAK -

8<---------- cut ----------->8

G. LIR-Portal - Leo Vegoda
http://www.ripe.net/ripe/meetings/archive/ripe-44/presentations/ripe44-lir-portal/

LV: We have seen that approx 540 LIRs have activated their LIR Portal since last Monday. How many people here today have activated their LIR Portal? (Positive reaction from majority of audience)

Live demonstration of LIR Portal by Manuel Valente (RIPE NCC) (MV).

https://lirportal.ripe.net/

Comments:

MV: This afternoon there is a tools working group where there will be a more technical demonstration and discussion on future plans for the LIR Portal. Everyone is invited.

LV: Further issues on the LIR Portal can be discussed during the tools working group.

HPH: Withdraws comments that RIPE NCC is a bit behind with new technology (interaction)!

8<---------- cut ----------->8

H. Mailing List AUP

HPH: There was one incident recently where members wanted a member removed from the list. If this happens in the future, the chair/co-chairs will discuss this and consult the RIPE NCC before warning the individual, and finally removing them.

No comments on this, so the assumption is that the working group is happy. No comments from the audience.

8<---------- cut ----------->8

I. WG name

HPH: What is the name of the WG?

*** A deathly silence descended upon the room ***

HPH: It's the "Local Internet Registry Working Group". Should the name be changed? Is this WG really only for LIRs? It has been proposed to change the name (see slide for full list).

Axel Pawlik (RIPE NCC): Results from survey indicate that newcomers are looking for a WG reflecting that it works on policies, so this word (policy) should appear in the name somewhere.

HPH: Did some research into past names (available for reference).

Rob Blokzijl (RIPE Chair): Agrees with Axel's reasoning. There are many people who are new, who might not know (from the name) what it is all about. The charter should outline this. Thinks that the name of the WG should be more self-explanatory. Should contain words such as "address" and "policy". However there is more to it than this, which is also important.

HPH: How shall we do this? At the RIPE dinner tomorrow? Should a Task Force be implemented?

HPH: Chair/co-chairs will get together a proposal will be circulated this week. 1st prize, a bottle of wine!

Action: Rob Blokzijl - publish a proposal this week.

8<---------- cut ----------->8

K. IPv6 Policy Experiences

HPH: There is an interim policy in place, should we go on with working on the next version? Gert did some calculations on 16m dialup users: we would need 24 bits address space to handle this. Same for mobile subscribers (10m).

David Kessens (Nokia): It would be a mistake to say that the policy does not allow for this.

GD: The problem for mobile networks is that they need to give each user a /64. Policy says that a /48 should be given. A way of working around the policy is to give each employee a /48 in order to reach 200 users.

DK: Not as big a problem as people think.

GD: Policy requires us to give out /48s. This is not what was intended.

DK: If you read between the lines, this is ok.

GD: Hostmasters don't read between the lines though.

HPH: Perhaps the policy is not clear enough? The WG should clarify it. This will make life easier. Decisions can be made without hesitation over policy interpretation.

WW: There are two aspects here: If the wording is ambiguous, and the requester interprets the policy in a different way to the Hostmaster, there is a collision of interests: Address management (conservation) versus the need to build a network. We should improve the wording of the policy. Perhaps Hostmasters can give us some input/feedback on that.

LV: The attitude we (RIPE NCC) try to adopt is to avoid being pedantic. Where there is ambiguity in someone's favour, we would prefer to give them the addresses rather than refuse the request. It is probably more favourable to give addresses in ambiguous situations rather than hinder their work. We're not trying to stop people from getting the resources they need.

Richard Jimmerson (ARIN): There has also been a policy discussion at ARIN regarding the requirement for 200 users within two years. ISPs are saying that they think they won't be able to get 200 users in two years and are therefore not even requesting the addresses. This is an ongoing discussion there.

GD: Has some feedback from German ISPs. Perhaps an ISP has 300 users now, and knows that 10 of them want IPv6 in two years. No-one can say for sure whether they will have 200 users in two years. The policy was intended to be more relaxed than is being interpreted.

Speaker: We would prefer a policy solution which does not encourage that we don't care why you need the addresses.

HPH: Could you clarify what you mean?

Speaker: If they have to care, they should not charge extra.

Randy Bush (IIJ) (RB): We should assume that IPv6 is infinite. Everyone should get what they want, never mind the implications.

HPH: Thanks for that Randy!

DK: A revision of the policy would make sense. It would clear up some issues. The smaller ISPs have bigger issues than mobile operators.

BT: We just need to be sure that people are actually using the resources that they request. Perhaps the forecasts shouldn't have to be for such a long time in the future, but that the requests are made for users for the coming months?

WW: Here we need to define 'users' more specifically. The technology behind the request is not really that important. We don't want to see a list of criteria "if you have a mobile phone, then...". It should be, "if you have the need for this many users", it shouldn't make any difference what technology they use.

GD: Agrees. The policy permits a /48 for this. (Reference to slide): If you do the maths, and give a /48 to everyone (no problem with people who need /20 getting one). The whole way that allocations are currently distributed to the RIRs (and LIRs) needs be revised,

HPH: Summary: There is a need to discuss this in more detail.

To clarify what was discussed during the break regarding the distribution of work between the chair and co-chair. Hans Peter Holen will continue as chair of the working group. Gert Doering will liaise between LIR-WG and IPv6 policy.

8<---------- cut ----------->8

J. PI Address Policy (see slides)

HPH: We missed this agenda point, so we'll go over it now. In the APNIC region, there is a new policy which accomodates critical structure. This could be of interest to the RIPE region. For example in Sweden, there is a desire to set addresses aside for root (DNS?) servers. Should this discussion be reopened?

RB: Technical considerations, global routing issues, and general arguments are not strong. Needs wider discussion than just the Registries.

HPH: This is a good point and also applies to the IPv6 issues.

Kurtis Lindqvist (Netnod Internet Exchange) (KL): Current policy doesn't take routing into consideration. Possible solution proposed by RIPE NCC was to go to another RIR, but he would prefer to get the space from his own RIR. Suggests to change policy to accomodate this. It's not easy, but it needs to be done.

GD: The only really critical infrastructure is root name servers. Everything else can be changed and renumbered, which might be painful, but is not critical.

HPH: If there is one critical server which needs a /32, the problem is not getting addresses, but getting routability. Should we change the policies to enforce routing on ISPs?

LV: There is a temptation to lie and say that you need more addresses that you actually have. We need a policy which doesn't encourage people to lie?

KL: We're an IXP, in this situation there is no other ISP to get the addresses from.

WW: We're now talking about routing interaction. This is the wrong WG for this.

RB: Agrees that the only critical servers are the global root servers. However, agrees with Kurtis Lindqvist that IXP are special. Remember that peers should not announce the IXP address space to each other (see NANOG presentation 1996). The routability of an IXP prefix is not an interesting question - just give them a /24!

Lars-Johan Liman (Autonomica AB) (LJL): Randy is correct, addresses which build the IXP shouldn't be announced. The problem is that the addresses for the services provided should be.

RB: Use a transit provider for this.

HPH: To clarify, since this is primarily of interest to Sweden, what should someone in Norway do when they want to look up a Swedish IXP?

RB: We all agree that the need to be globally routed. Lars-Johan Liman asks which transit provider he should get it from. It makes no difference - choose the one with the lowest price! IXPs are the same as any other multi-homed customer. Also ccTLD servers don't need special treatment.

Speaker: Group servers don't need special treatment since ISPs rewrite filters to include them. IXPs only need to be announced down through transit. Other critical servers - doesn't see any reason why they need special address space.

LJL: When a customer leaves, we have to renumber.

KL: The problem is that an IXP is no different, except that they are not large enough to need (routable) address space.

HPH: To summarise, there is a policy to provide PI space which should not take routing issues into account. In Sweden this is seen as a large problem, but no-one else seems to be interested in discussing it.

LJL: Propose a question. Please suggest a method of getting address space for providing services at an IXP?

WW: This problem doesn't seem to be of great interest to the community at large.

HPH: Suggests to create a task force comprising of Lars-Johan, WW and Kurtis to investigate.

All: Agreed

8<---------- cut ----------->8

L. IP Addressing policy for always-on (residential broadband) revisited.

HPH: As a provider of ADSL/Cable services, we want to offer a good service. Could you (RIPE NCC) please tell us if there are any exceptions to the normal rules?

LV: We try to be technology agnostic. If your AW allows it, then do it. We try to make sure that the usage is as LIRs say.

HPH: If a customer connects with a PC, he gets one address. If he then connects a further PC, he gets another. Is there anything to restrict the numbers of IP addresses which can be made available to customers?

LV: I am not aware of any policy limitations.

HPH: Then if we change from DHCP to assigning a /24 to one customer who has large number of PCs at home.

LV: This should be registered in the database. If it's a residential user, their personal contact information cannot be registered in most countries due to the Data Protection laws. The Database object could then point to contact data at the ISP without identifying customer by name. This should be discussed by the WG if anyone is concerned by this.

HPH: Thanks for this - it has clarified my thoughts.

Mobile Operators:

Speaker: We see more people wanting public addresses for GPRS as they cannot use NAT. Numbers of users can be large. Addresses are sometimes almost statically assigned. This then starts to look like fixed assignments. The IR 40 document (Feb 2001), talks primarily about WAP. In the future, GPRS usage is going to grow more. Global Coorporate customers are going to need large numbers of addresses for this and I don't think that the policy addresses this sufficiently.

DK: You should qualify if you have the need for the addresses. This (IR 40) isn't a policy document though. There is no reason mobile operators should be treated any differently.

Speaker: I wasn't suggesting it was a policy document. Only saying that this could be a problem in the near future.

DK: If you need 100,000 addresses, you will get them. The policy doesn't currently prohibit this.

GD: Agrees with David Kessens. If you have the need, the policy allows you to have the addresses. Otherwise, go for IPv6.

RB: There is no reason why you should have to justify why you don't use NAT.

LV: The wording in the old policy document was unclear. There is nothing to say you have to use NAT. The document is being rewritten and this will be clearer.

RB: NAT is also poisonous

LV: If people want us to change the wording again, they can discuss better wording once the draft is published.

Speaker: It (IR40) seems to be more of a resource and is maybe out-of-date. Will take it to the list to suggest rewriting.

HPH: Bear in mind that this document was written by the GSM association.

DK: RIPE NCC should never refer to this document.

HPH: Let's work on improving the GSM association document.

DK: There is no need for this if no-one refers to it.

8<---------- cut ----------->8

M. Summary of ALLOCATED and ASSIGNED variants - both for v4 and v6 - Wilfried Woeber

HPH: This is Wilfried's area of expertise, so over to him.

WW: There needs to be some definition of the labels. What are the values, who can use them, and in which context? Suggested to think primarily about the number of variants, and also who is allowed to use them.

HPH: RIPE NCC is in progress of writing document to describe these values. The draft will be published for further comments.

8<---------- cut ----------->8

N. EGLOP Multicast Policy Discussion - Marc-Olivier M=E9hu

HPH: Could you please clarify this point?

Marc-Olivier M=E9hu (NAINO) (MOM): BCP 53 defines GLOP space. RFC 3138 defines EGLOP space (it relates to private ASNs). It also says that the policies for assigning this space are determined by the RIR communities.

GD: We have been using four of them. We would use a customer's ASN to get more. Either go to IANA or use GLOP.

MOM: So should I steal address space from a customer?

GD: As long as they have an ASN.

MOM: And if they don't?

HPH: You could discuss it on the mailing list in that case.

MOM: Can someone help me with this?

HPH: RIPE NCC should help publish a draft RIPE document as soon as a proposal has been discussed on the mailing list.

8<---------- cut ----------->8

X. AOB

8<---------- cut ----------->8

Y. Summary of OPEN actions

Action: Action on: Action description : Status :

35.4 NCC PGP Key exchange procedure In Progress

36.7 NCC Keep lir-wg updated on pre RIR address space changes (Early Registration Transfer ERX) In Progress (long term)

38.2 NCC Implement changes to the form while taking into account the comments from the WG. In Progress

38.4 AC Consider how to coordinate Address prediction work. Work Launced

39.4 Chairs Define & divide work. Unknown

39.5 Chairs Beta test 6 weeks deadline for proposals. Move to 2nd beta. Unknown

40.5 WG Join RFC2050 mailinglist to give input to revision Unknown

40.6 WG Produce drafts to replace 2050 for discussion by wg. In progress

43.4 NCC Continue the process to move 6bone under the framework of the RIRs. Open

43.5 NCC Present AS statistics, allocated, announced etc... In Progress

44.1 RIPE Chair WG name change proposal Open

44.2 Chairs/NCC Create PI policy reviewing task force (PI-TF) Done

44.3 PI-TF PI Policy review Open

8<---------- cut ----------->8

Z. Open Microphone

No further comments.

Everyone proceeds to the Wintertuin for luncheon

--Fin--