- ipv6-wg - mailman.ripe.net

ETNO position on IPv6 addressing policy
by COLOMB Jean-Marc BRX/DRSA/DOR 10 May '01

10 May '01

Dear Colleagues, As I have announced at the last RIPE meeting, I am posting for your information the ETNO Common Position on IPv6 policy, to be used as an input into the ongoing discussions on this issue. For those who have not attended the last WG meeting, ETNO is the principal European trade association of network operators, gathering 45 operators and LIRs at the same time (www.etno.be) It includes both historic operators and new entrants. Some of them already have been granted IPv6 addresses. I have been chairing the Naming, Addressing and Numbering Issues (NANI) WG of ETNO for some years. The following position has been signed up by all 45 members of ETNO, further to the drafting work led by Niall. It is now available on the ETNO site at http://www.etno.be/ETNO positions/latest position papers. ETNO supports /29 because it is consistent with the current allocation policy as defined by the RIRs and better fits the LIRs' needs than the current /35. Indeed, ETNO considers /29 as a minimum allocation size to allow a sub-TLA registry to run its activities efficiently. The rationale for a wider address block for operators acting as LIRs lies in aggregation, efficiency of routing tables and better management of address space by TLA registries. These registries need enough space to serve their customers and NLA registries in the best possible way. Quote "ETNO Common Position on IPv6 addressing policy The foreseeable needs for public addresses for the coming years, especially for UMTS, DSL, cable modemsï¿½ is a source of concern for operators and the Internet community as a whole. According to BT's estimates presented at the RIPE 38 meeting in Amsterdam and agreed by the participants, it can be expected that the IPv4 space will reach exhaustion in the most likely case around 2005 - 2007. Therefore, it is in the Internet community's interest to stimulate at the soonest a broad usage of IPv6 addresses, where no shortage should exist in theory. It is the ETNO opinion that such stimulation can only be obtained by setting up rules of management of IPv6 addresses that would avoid at the same time: ï¿½ to introduce artificial limitations that might hamper the move to Ipv6, ï¿½ an exaggerated increase of routing tables. However, ETNO notes the current policies consisting of the: ï¿½ allocation to Top Level Aggregation (TLA) registries of /35 addressing space ï¿½ reservation by the RIRs of six additional bits together with the new proposal for the systematic assignment of /48 to end users potentially running sub networks, as agreed at RIPE 37. This does not allow TLA registries to efficiently manage their addressing space in a long term perspective, nor to properly allocate addresses to their Next Level Aggregation (NLA) registries and assign addresses to end users, since their available space is reduced to 13 bits. ETNO favours a structure that permits maximum aggregation. This would enable operators and ISPs to structure their addressing plan in a long-term perspective. Therefore ETNO strongly supports the idea presented at RIPE 38 to allocate from now on /29 to all TLA registries, including the existing ones. In the same spirit of facilitating a timely move to IPv6, ETNO also suggests that the opportunity be taken at the end of the bootstrap period, expected end 2001, to review and ease the conditions for registries to be allocated IPv6 addresses." Unquote Jean-Marc Colomb Chairman ETNO NANI WG

1 0

IPv6 Bootstrap Phase
by Mirjam Kuehne 07 May '01

07 May '01

Dear colleagues, As discussed at RIPE 39 in Bologna last week, we have almost reached the end of the bootstrap phase for IPv6 allocations as originally defined in the "Provisional IPv6 Assignment and Allocation Policy Document": 4.2.2.1. Duration of Bootstrap Phase " The eligibility criteria in this section will only apply until 100 requesting organisations have received allocations of sub-TLA address space, provided that no more than 60 of these organisations are located in one Regional IR's region. After this threshold has been reached, the bootstrap phase will be considered to be over and Regional IRs will only make allocations to organisations that meet the general criteria in section 4.2.1. " The Regional Internet Registries (RIRs) have jointly made almost 80 IPv6 allocations to date. At the RIPE meeting it was suggested to continue allocating under the bootstrap criteria until 100 allocations have been made and to further extend the bootstrap phase. No specific end for the bootstrap phase has been suggested. The RIRs will inform the community as soon as 100 IPv6 allocations have been made. Kind Regards, Mirjam Kuehne RIPE NCC

1 0

agenda for IPv6 working group RIPE39
by David Kessens 29 Apr '01

29 Apr '01

Hi, Below follows the final version of the agenda for the ipv6 wg. The second part of our session will be used for ipv6 policy discusions. This part will be a joint session with the local-ir working group. Thanks, David K. --- Agenda for the IPv6 Working Group Meeting RIPE39, Bologna Tuesday, May 1, 2001, 14:00-17:30 1st part 14:00-15:30 A. Administrative stuff - appointment of scribe - agenda bashing (David Kessens) B. Status of the 6bone (David Kessens) C. Securing the Mobile-IPv6 Binding Update (Tony Hain) D. 3G and IPv6 (Niall Murphy) E. IPv6 deployments at Jippii (Jan-Ahrent Czmok) F. Developments/initiatives regarding IPv6 in the RIPE region and beyond (input from the audience) 2nd part 16:00-17:30 joint session with lir-wg G. Draft on allocation sizes http://www.enigma.ie/articles/global-ipv6-alteration.html (Niall Murphy) other info: http://www.djp.net/ipv6/proposal.html http://www.ripe.net/ripe/mail-archives/ipv6-wg/20010101-20010401/msg00017.h… (Dave Pratt) H. Status of IETF/RIR allocation boundary discussions (Randy Bush/Mirjam Kuehne) Z. AOB ---

1 0

Fw: ipngwg / ngtrans interim meeting
by Thomas Trede 25 Apr '01

25 Apr '01

FYI. Regards, Thomas Trede ----- Original Message ----- From: "Steve Deering" <deering(a)cisco.com> To: <ipng(a)sunroof.eng.sun.com>; <ngtrans(a)sunroof.eng.sun.com> Sent: Wednesday, April 25, 2001 3:44 AM Subject: Re: ipngwg / ngtrans interim meeting > Further regarding the interim meeting, here's the rough outline of > the planned use of the three days: > > Wednesday, May 30 > > 9:00 - 9:30 Introductions, Local Arrangements, Etc. > > 9:30 - 17:00 Joint meeting with 3GPP community, to discuss > details of the use of IPv6 in forthcoming 3GPP > Standards. > > Thursday, May 31 > > 9:00 - 17:00 IPv6 working group meeting > > Friday, June 1 > > 9:00 - 12:00 IPv6 working group meeting > > 13:00 - 17:00 NGtrans working group meeting > > > If necessary to provide sufficient discussion time, the meetings may > be extended into the evenings of Wednesday and/or Thursday. > > IPv6 Working Group topics will include: > > - Follow-up from 3GPP discussions > - Flow Label definition > - Scoped Address Architecture > - Updates to Addressing Architecture and Unicast Aggregation specs > - Site renumbering guidelines > - DNS discovery > - (other topics to-be-determined) > > > NGtrans Working Group topics will include: > > - Intra-site tunneling techniques > - review of the different tunneling mechanisms in the context > of intra-site communications > - resolution of issues around the isatap proposal > > - Transition tool combination matrix > - scoping the mechanisms to break the matrix into smaller > components > - reviewing the compatibility issues > > - (other topics to-be-determined) > > > Please send requests for additional agenda topics to the chairs of > the appropriate working group. > > Steve > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo(a)sunroof.eng.sun.com > -------------------------------------------------------------------- >

1 0

Fw: ipngwg / ngtrans interim meeting
by Thomas Trede 25 Apr '01

25 Apr '01

FYI. Regards, Thomas Trede ----- Original Message ----- From: "Steve Deering" <deering(a)cisco.com> To: <ipng(a)sunroof.eng.sun.com>; <ngtrans(a)sunroof.eng.sun.com> Cc: <ietf(a)ietf.org> Sent: Tuesday, April 24, 2001 11:56 PM Subject: ipngwg / ngtrans interim meeting > Information about the interim meeting of the IPv6 working > groups on May 30, 31, and June 1 is now available at http://research.microsoft.com/ietf-ipv6-meeting. > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo(a)sunroof.eng.sun.com > -------------------------------------------------------------------- >

1 0

IPv6 addresses for Exchange Points
by Mirjam Kuehne 24 Apr '01

24 Apr '01

[Appologies for multiple postings. I suggest to keep the discussion on <lir-wg(a)ripe.net> as it is related to address allocation policies]. Dear colleagues, The RIPE NCC received a number of requests from Internet Exchange Points (IXPs) for IPv6 address space. While evaluating these requests, we realised that it is still not entirely clear what the role of an IXP is in the IPv6 world. We also noticed that the allocation criteria currently described in the 'Provisional IPv6 Assignment and Allocation Policy Document' (http://www.ripe.net/ripe/docs/ripe-196.html) do not necessarily apply to IXPs. Please find some more details regarding this issue below. We would like to discuss this with you at the upcoming RIPE Meeting in Bologna. For more information abut the schedule, please refer to the agenda of the EIX-WG and the LIR-WG: http://www.ripe.net/ripe/meetings/current/ripe-39/ Kind Regards, Mirjam Kuehne RIPE NCC ------------ PROBLEM STATEMENT: - IXPs need independent address space for their infrastructure to allow their members/customers to connect via native IPv6 - IXPs do not necessarily fulfill the current criteria: - they do not have 40 customers (in most cases IXPs do not assign address space to their members) - if IXPs are on the 6bone, they might not have a whole pTLA, but only connect to the 6bone via another ISP - they do not need a whole subTLA (a /64 or /48, depending on the case, might be enough) POSSIBLE SOLUTIONS: 1. view IXPs as a site and assign them a /48 (or /64) directly (equivalent to IPv4 PI space) 2. require IXPs to fulfill the criteria and allocate a subTLA: - either by requiring them to get 6bone experience first - or by applying the general allocation criteria and require to connect to 3 other subTLA holders OPEN ISSUES: - what about IXPs with multiple PoPs - technical criteria for exchange points

1 0

draft agenda (v2) for IPv6 working group RIPE39
by David Kessens 24 Apr '01

24 Apr '01

Hi, Below follows the second draft of the agenda for the ipv6 wg. The current plan is to use the second part of our session for ipv6 policy discusions. This part will be a joint session with the local-ir working group. This draft agenda will be used for the printed version of the agenda. However, I am still accepting additions to the agenda until friday. Please let me know if you have any other topics that you want to have discussed or if you would like to volunteer for a presentation. We still have some time left in our agenda for additional topics. Thanks, David K. --- Agenda for the IPv6 Working Group Meeting RIPE39, Bologna Tuesday, May 1, 2001, 14:00-17:30 1st part 14:00-15:30 A. Administrative stuff - appointment of scribe - agenda bashing (David Kessens) B. Status of the 6bone (David Kessens) C. Securing the Mobile-IPv6 Binding Update (Tony Hain) D. IPv6 deployments at Jippii (Jan-Ahrent Czmok) E. Developments/initiatives regarding IPv6 in the RIPE region and beyond (input from the audience) 2nd part 16:00-17:30 joint session with lir-wg F. Draft on allocation sizes (Niall Murphy) G. Status of IETF/RIR allocation boundary discussions (Randy Bush/Mirjam Kuehne) Z. AOB ---

4 4

Fw: I-D ACTION:draft-ietf-ipngwg-ipv6-2260-01.txt
by Thomas Trede 19 Apr '01

19 Apr '01

FYI. Regards, Thomas Trede ----- Original Message ----- From: <Internet-Drafts(a)ietf.org> To: <IETF-Announce: ;> Cc: <ipng(a)sunroof.eng.sun.com> Sent: Friday, April 13, 2001 1:15 PM Subject: I-D ACTION:draft-ietf-ipngwg-ipv6-2260-01.txt > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IPNG Working Group of the IETF. > > Title : IPv6 multihoming support at site exit routers > Author(s) : J. Hagino > Filename : draft-ietf-ipngwg-ipv6-2260-01.txt > Pages : 9 > Date : 12-Apr-01 > > The document describes a mechanism for basic IPv6 multihoming support, > and its operational requirements. The mechanism can be combined with > more sophisticated (or complex) multihoming support mechanisms, and can > be used as a foundation for other mechanisms. The document is largely > based on RFC2260 [Bates, 1998] by Tony Bates. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-ipv6-2260-01.txt > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-ipngwg-ipv6-2260-01.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv(a)ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-ipngwg-ipv6-2260-01.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. >

1 0

draft agenda (v1) for IPv6 working group RIPE39
by David Kessens 19 Apr '01

19 Apr '01

Hi, Below follows the first draft of the agenda for the ipv6 wg. The current plan is to use the second part of our session for ipv6 policy discusions. This part will be a joint session with the local-ir working group. Please let me know if you have any other topics that you want to have discussed or if you would like to volunteer for a presentation. We still have some time left in our agenda for additional topics. Thanks, David K. --- Agenda for the IPv6 Working Group Meeting RIPE39, Bologna Tuesday, May 1, 2001, 14:00-17:30 1st part 14:00-15:30 A. Administrative stuff - appointment of scribe - agenda bashing (David Kessens) B. Status of the 6bone (David Kessens) C. Securing the Mobile-IPv6 Binding Update (Tony Hain) D. Developments/initiatives regarding IPv6 in the RIPE region and beyond (input from the audience) 2nd part 16:00-17:30 joint session with lir-wg E. Draft on allocation sizes (Niall Murphy) F. Status of IETF/RIR allocation boundary discussions (Randy Bush/Mirjam Kuehne) Z. AOB ---

1 0

Fw: Protocol Action: Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification to Proposed Standard
by Thomas Trede 09 Apr '01

09 Apr '01

FYI. Regards, Thomas Trede ----- Original Message ----- From: "The IESG" <iesg-secretary(a)ietf.org> To: <IETF-Announce: ;> Cc: "RFC Editor" <rfc-editor(a)isi.edu>; "IANA" <iana(a)iana.org>; "Internet Architecture Board" <iab(a)isi.edu>; <ipng(a)sunroof.eng.sun.com> Sent: Friday, April 06, 2001 9:31 PM Subject: Protocol Action: Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification to Proposed Standard > > > The IESG has approved the Internet-Draft 'Extensions to IPv6 Neighbor > Discovery for Inverse Discovery Specification' > <draft-ietf-ion-ipv6-ind-05.txt> as a Proposed Standard. This document > is the product of the IPNG Working Group. The IESG contact persons are > Erik Nordmark and Thomas Narten. > > > Technical Summary > > This protocol describes extensions to the IPv6 Neighbor Discovery that > allow a node to determine and advertise an IPv6 address corresponding > to a given link-layer address. The extensions are called Inverse > Neighbor Discovery. They were originally developed for Frame Relay > networks but may also apply to other networks with similar behavior. > > Working Group Summary > > This document was originally developed within the ION WG but was moved > to the IPng WG because it extended IPv6's Neighbor Discovery. There > was concensus in the WG for the extensions defined in this document. > > Protocol Quality > > This document has been reviewed for the IESG by Thomas Narten. > > Note to RFC Editor: > > In the "References" section, there is a work in progress that > needs to be updated: > > [IPv6-FR] citation needs to have the title change: > "Transmission of IPv6 Packets over Frame Relay", > and update with its RFC number - RFC 2590, May 1999. > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo(a)sunroof.eng.sun.com > -------------------------------------------------------------------- >

1 0