August 2001 - ipv6-wg - mailman.ripe.net

Interim Policy proposal for IPv6 Address Assignment Policy for Internet Exchange Points
by Fearghas McKay 03 Sep '01

03 Sep '01

Following discussion between the WG-Chairs and the NCC we have the following proposed draft. To enable allocations to be made as soon as possible we are soliciting comments over the next few days but unless there are any issues we would like to start making allocations by the end of next week, ie 7th September 2001. Please send any comments to the LIR-WG list <lir-wg(a)ripe.net> We propose a joint session to be held at RIPE40 where we can discuss the initial size allocations, information required in the forms and other issues raised by the community after which we will formalise the proposal. Thanks Fearghas EIX-WG Chair -- IPv6 Address Assignment Policy for Internet Exchange Points =========================================================== 1. Abstract ----------- This document describes a policy for Internet Exchange Points (IXPs) under which unique IPv6 address space to be used for the infrastructure of the Internet Exchange Point can be obtained from a Regional Internet Registry (RIR). 2. Background ------------- It has been recognised that there are scenarios in which it is not desirable for IXPs to obtain address space from one of the Internet Service Providers (ISPs) connecting at the IXP. In these cases it is viable to have unique IPv6 address space assigned directly from an RIR. This address space is needed to adress the Exchange fabric. This issue has been brought forward to the RIPE community in May 2000 and has subsequently been discussed at RIPE Meetings and on public RIPE mailing lists. The conclusions of these discussions are described in this document. It is expected that the same policy will be accepted in the ARIN and the APNIC region at which point it will be incorporated in the Global IPv6 Policy document. 3. Definition ------------- An Internet Exchange Point is defined as a physical network infrastructure (layer 2) operated by a single entity with the purpose to facilitate the exchange of Internet traffic between Internet service providers. The number of Internet Service providers connected should at least be three and there must be a clear and open policy for others to join. Addresses needed for other purposes (e.g. additional services provided to the members) should be aquired through other appropriate means ( e.g. an upstream ISP). 4. Policy --------- An IXP that seeks to obtain an IPv6 address assignment by the RIR in its region, needs to submit a request to that RIR. IXPs operating in the RIPE NCC service region should use the 'IPv6 Request Form for Internet Exchange Points' (http://www.ripe.net/ripe/docs/ipv6request-exchangepoint.html) After approval of the request, the RIR will make the assignment. Since the address space does not need to be routable globally and an IXP is expected to only have one subnet, a /64 (64 bits of address space) will be assigned in most cases. In the case the IXP is using multiple fabrics (e.g. unicast separated for multicast), multiple /64s can be assigned to the IXP. IP Address requests can only be handled if the requestor is a Local Internet Registry (LIR) or if the request made through an existing LIR. 5. Other Considerations ----------------------- It should be noted that ISPs usually do not announce address space used on the IXP mesh itself to their peers. That means the address space assigned under this policy is likely not to be routable globally.

6 8

Interim Policy discussion
by David Kessens 31 Aug '01

31 Aug '01

This is a request to keep our discussion focused: - let's try to keep the discussion on lir-wg. - the proposed policy is an interim policy, that means further changes can be and will made to the policy after it has been approved. we don't have to discuss all those changes right now, *unless* you cannot live with the interim policy at all without such changes. - the policy is not intended to solve all problems to everybody. I hope this helps, David K. ---

1 0

WG: I-D ACTION:draft-gopinath-host-name-resolution-protocol-ipv6-00.txt
by Thomas Trede 31 Aug '01

31 Aug '01

FYI. Regards, Thomas Trede -----Ursprï¿½ngliche Nachricht----- Von: owner-ipng(a)sunroof.eng.sun.com [mailto:owner-ipng@sunroof.eng.sun.com]Im Auftrag von Internet-Drafts(a)ietf.org Gesendet: Donnerstag, 30. August 2001 13:14 An: IETF-Announce: Cc: ipng(a)sunroof.eng.sun.com Betreff: I-D ACTION:draft-gopinath-host-name-resolution-protocol-ipv6-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Host Name Resolution Protocol (HNRP) for IPv6 nodes Author(s) : G. Sinniah et al. Filename : draft-gopinath-host-name-resolution- protocol-ipv6-00.txt Pages : 13 Date : 29-Aug-01 This document describes a new method, which will automatically acquire the host name of active IPv6 nodes and register it to the local Domain Name System (DNS) server. Active IPv6 nodes are nodes that are connected to a network. Our proposed new protocol, which is called Host Name Resolution Protocol (HNRP) [6], will automatically learn some useful information from all the IPv6 nodes, such as the host name and the IP address. All the information will be kept by HRRP and the host name together with the IPv6 address will be added to the DNS. This will be implemented without the need for any changes at the clients' site. The objective of this document is to specify the new Host Name Resolution Protocol and also the algorithm used in the protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-gopinath-host-name-resolution-prot ocol-ipv6-00.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-gopinath-host-name-resolution-protocol-ipv6-00.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-gopinath-host-name-resolution-protocol-ipv6-00.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. ENCODING mime FILE /internet-drafts/draft-gopinath-host-name-resolution-protocol-ipv6-00.txt

1 0

WG: I-D ACTION:draft-roesler-ipngwg-ipngls-00.txt
by Thomas Trede 31 Aug '01

31 Aug '01

FYI. Regards, Thomas Trede -----Ursprï¿½ngliche Nachricht----- Von: owner-ipng(a)sunroof.eng.sun.com [mailto:owner-ipng@sunroof.eng.sun.com]Im Auftrag von Internet-Drafts(a)ietf.org Gesendet: Donnerstag, 30. August 2001 13:14 An: IETF-Announce: Cc: ipng(a)sunroof.eng.sun.com Betreff: I-D ACTION:draft-roesler-ipngwg-ipngls-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IPNGLS - IP Next Generation Label Switching Author(s) : V. Roesler et al. Filename : draft-roesler-ipngwg-ipngls-00.txt Pages : 17 Date : 29-Aug-01 This document proposes the forwarding of IPv6 packets using label switching techniques, with the same advantages of the Multiprotocol Label Switching (MPLS) architecture. The document proposes the mapping of all MPLS header fields into the IPv6 header, raising several advantages like the simplicity of the model, the decrease of overhead, and others. This mapping was called IP Next Generation Label Switching, or just IPngLS, and can work concurrently with MPLS, i.e. IPv6 packets are forwarded with IPngLS and IPv4 packets are forwarded with MPLS. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-roesler-ipngwg-ipngls-00.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-roesler-ipngwg-ipngls-00.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-roesler-ipngwg-ipngls-00.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. ENCODING mime FILE /internet-drafts/draft-roesler-ipngwg-ipngls-00.txt

1 0

Re: IPv6 request form for Internet Exchange Points
by Fearghas McKay 29 Aug '01

29 Aug '01

Nurani, On Fri, Aug 17, 2001 at 09:38:48AM +0200, Nurani Nimpuno wrote: > > Following the consensus reached in the community on assigning IPv6 > address space to Internet Exchange Points, the RIPE NCC is now > starting to make IPv6 assignments to requesting Internet Exchange > Points. We don't really think that consensus has been reached yet. We have discussed lot's of details at the mailing list, but the community at large did not have a chance yet to approve a final proposal. As chairpeople of two of the respective working groups, we asked the RIPE NCC to schedule a slot at the next meeting in order to have a final discussion regarding this very topic. We invite you to do a presentation on the next meeting of what you think that the status of the discussion is so far and to send a document to the mailing list some time before the meeting that describes the proposed policy based on the input from the discussions that we had on the mailing list. >From there, we the chairpeople can ask the RIPE community at the next meeting whether they approve and possibly make some small adjustments or whether we have to go back to the drawing board and need more discussion. We would like to ask you to suspend the proposed policy until we have had a chance to ask the RIPE community for approval. Meanwhile we suggest that discussion continues on the LIR-WG list. Thanks, Fearghas McKay, chairperson eix wg David Kessens, chairperson ipv6 wg At 9:38 am +0200 17/8/01, Nurani Nimpuno wrote: >Dear all, > >Following the consensus reached in the community on assigning IPv6 >address space to Internet Exchange Points, the RIPE NCC is now >starting to make IPv6 assignments to requesting Internet Exchange >Points. > >A specific request form has been created for this purpose, "IPv6 >Request Form for Internet Exchange Points" which can be obtained at >the RIPE document store at: > >http://www.ripe.net/ripe/docs/ipv6request-exchangepoint.html > >Pending requestors will be asked to complete this form in order to >receive an IPv6 assignment from the RIPE NCC. > >We wish to thank all participants of this discussion for the >constructive input in this matter. > >Kind regards, > >Nurani Nimpuno > >*--------------------------------------------------------* >| Nurani Nimpuno <nurani(a)ripe.net> | >| Internet Address Policy Manager | >| RIPE Network Co-ordination Centre | >| http://www.ripe.net | >*--------------------------------------------------------*

6 8

WG: W.G. Last Call on "An analysis of IPv6 anycast"
by Thomas Trede 27 Aug '01

27 Aug '01

FYI. Regards, Thomas Trede -----Ursprungliche Nachricht----- Von: owner-ipng(a)sunroof.eng.sun.com [mailto:owner-ipng@sunroof.eng.sun.com]Im Auftrag von Bob Hinden Gesendet: Freitag, 24. August 2001 23:19 An: ipng(a)sunroof.eng.sun.com Betreff: W.G. Last Call on "An analysis of IPv6 anycast" This is a IPng working group last call for comments on advancing the following document as an Informational RFC: Title : An analysis of IPv6 anycast Author(s) : J. Hagino et al. Filename : draft-ietf-ipngwg-ipv6-anycast-analysis-00.txt Pages : 10 Date : 16-Jul-01 Please send substantive comments to the ipng mailing list, and minor editorial comments to the author. This last call period will end two week from today on September 7, 2001. Bob Hinden / Steve Deering -------------------------------------------------------------------- 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

WG: W.G. Last Call on "IP Version 6 Addressing Architecture"
by Thomas Trede 27 Aug '01

27 Aug '01

FYI. Regards, Thomas Trede -----Ursprungliche Nachricht----- Von: owner-ipng(a)sunroof.eng.sun.com [mailto:owner-ipng@sunroof.eng.sun.com]Im Auftrag von Bob Hinden Gesendet: Samstag, 25. August 2001 00:58 An: ipng(a)sunroof.eng.sun.com Betreff: W.G. Last Call on "IP Version 6 Addressing Architecture" This is a short IPng working group last call for comments on advancing the following document as an Draft Standard: Title : IP Version 6 Addressing Architecture Author(s) : B. Hinden, S. Deering Filename : draft-ietf-ipngwg-addr-arch-v3-06.txt Pages : 27 Date : 19-Jul-01 A complete list of changes from RFC-2373 is in Appendix B of the draft and is reproduced below. Please send substantive comments to the ipng mailing list, and minor editorial comments to the authors. This last call period will end one week from today on August 31, 2001. We are doing a short w.g. last call because there have been earlier w.g. and IETF last calls on this document and wanted to insure that the changes in the current draft has been reviewed by the w.g. Bob Hinden / Steve Deering -------------------------------------------------------------------------- APPENDIX B: Changes from RFC-2373 --------------------------------- The following changes were made from RFC-2373 "IP Version 6 Addressing Architecture": - Many small changes to clarify and make the text more consistent. - Revised sections 2.4 and 2.5.6 to simplify and clarify how different address types are identified. This was done to insure that implementations do not build in any knowledge about global unicast format prefixes. Changes include: o Removed Format Prefix (FP) terminology o Revised list of address types only includes exceptions to global unicast and a singe entry that identifies everything else as Global Unicast. o Removed list of defined prefix exceptions from section 2.5.6 as it is now the main part of section 2.4. - Clarified text relating to EUI-64 identifiers to distinguish between IPv6's "Modified EUI-64 format" identifiers and IEEE EUI-64 identifiers. - Combined the sections on the Global Unicast Addresses and NSAP Addresses into a single section on Global Unicast Addresses, generalized the Global Unicast format, and cited [AGGR] and [NSAP] as examples. - Reordered sections 2.5.4 and 2.5.5. - Removed section 2.7.2 Assignment of New IPv6 Multicast Addresses because this is being redefined elsewhere. - Added an IANA considerations section that updates the IANA IPv6 address allocations and documents the NSAP and AGGR allocations. - Added clarification that the "IPv4-compatible IPv6 address" must use global IPv4 unicast addresses. - Divided references in to normative and non-normative sections. - Added reference to [PRIV] in section 2.5.1 - Revised section 2.4 Address Type Representation to - Added clarification that routers must not forward multicast packets outside of the scope indicated in the multicast address. - Added clarification that routers must not forward packets with source address of the unspecified address. - Added clarification that routers must drop packets received on an interface with destination address of loopback. - Clarified the definition of IPv4-mapped addresses. - Removed the ABNF Description of Text Representations Appendix. - Removed the address block reserved for IPX addresses. - Multicast scope changes: o Changed name of scope value 1 from "node-local" to "interface- local" o Defined scope value 3 for "subnet-local" for multi-link subnets o Defined scope value 4 as "admin-local" - Corrected reference to RFC1933 and updated references. ------------------------------------------------------------------------ -------------------------------------------------------------------- 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

Re: IPv6 request form for Internet Exchange Points
by Nurani Nimpuno 23 Aug '01

23 Aug '01

All, When concluding the discussion on IPv6 addresses for IXPs, the RIPE NCC were under the impression that participants in the discussion felt that they had had ample time to discuss the final proposed policy. Mirjam sent out a summary on the lists 28 June 2001 after the intense discussion both at the last RIPE meeting and on the mailing lists. (http://www.ripe.net/ripe/mail-archives/lir-wg/20010401-20010701/msg00 228.html) There were a few comments on actual wording that Mirjam took into account, but no further discussion. No objections were raised to the proposed definition. The RIPE NCC has several pending requests for IPv6 address space from IXPs that have been waiting since April. After such lengthy discussion and no further input from the community, we therefore felt that it would be appropriate to move forward and implement the concluded policy in order to meet the need of these LIRs. We do of course recognise the great importance of ensuring that the policy that the RIPE NCC implements is the one agreed upon by the community. This is essential. We also recognise the need for improving the co-ordination between the working group chairs and the RIPE NCC. We hope to discuss this further with the chairs. Some comments have been made on the list suggesting the RIPE NCC to not further postpone the evaluation of the currently pending IXP requests. If this reflects the general feeling in the community, then the RIPE NCC is ready to move forward and do so. If however, there is a need for further discussion, then we wish to encourage everyone to actively contribute with their comments. I hope that there is no need to postpone this discussion until the RIPE 40 meeting in October. I trust the working group chairs to propose a way forward that will ensure a fair and correct conclusion of this discussion. Kind regards, Nurani *--------------------------------------------------------* | Nurani Nimpuno <nurani(a)ripe.net> | | Internet Address Policy Manager | | RIPE Network Co-ordination Centre | | http://www.ripe.net | *--------------------------------------------------------* "Hans Petter Holen" <hph(a)online.no> writes: * | Agreed!!! I understand the need to ensure complete consensus regarding * | allocation, but *please* can we aim for a temporary work around to allow * | us to get an allocation using the existing document. * | * | We could review the interim allocations once the consensus is finally * | reached, and supply any new information then _if_ needed. But as Robert * | says, this has gone on far too long already! * * Would this be a way to proceede; * introduce the procedure proposed by Nurani as an interim procedure * in order to get this thing rolling ? * * Nothing is worse than technology and customers waiting for politicians * to make up their mind... * * * -hph *

1 0

Global IPv6 Policy Document
by Mirjam Kuehne 22 Aug '01

22 Aug '01

Dear LIRs, I am happy to inform you that the first draft of the Global IPv6 policies document is ready for a collective review by the RIRs. This draft incorporates the results of discussions that took place at open policy meetings and intensive meetings among the RIRs and the IETF. This review will also allow time for APNIC to present some of the new developments already discussed in the ARIN and RIPE community to its community at the upcoming APNIC open policy meeting on 28 - 31 August. As agreed at RIPE 39, following the RIR revision, the document will be sent to an editorial team for review. We hope to have a final draft ready to publish to the LIR-WG approximately 3 weeks prior to the RIPE 40 Meeting. However, this relies on the reactions from both the APNIC community and the editorial team. Thank you for all the useful contributions made so far. Regards, Mirjam Kuehne RIPE NCC

2 1

New Document available: RIPE-224
by RIPE NCC Document Announcement Service 16 Aug '01

16 Aug '01

New RIPE Document Announcement -------------------------------------- A new document is available from the RIPE document store. Short content description ------------------------- This document contains the set of templates to be used when submitting an "IPv6 Request Form for Internet Exchange Points". Accessing the RIPE document store --------------------------------- The RIPE document store is available via anonymous FTP to ftp.ripe.net, in the directory ripe/docs. The URLs for the new documents on the FTP-server are: ftp://ftp.ripe.net/ripe/docs/ripe-224.ps PostScript version ftp://ftp.ripe.net/ripe/docs/ripe-224.txt plain text version You can also access the RIPE documents in HTML format via WWW. RIPE-224 is available from the WWW at the following URL: http://www.ripe.net/docs/ipv6request-exchangepoint.html

1 0