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

Re: 90 IPv6 sub-TLA allocations made
by James Aldridge 15 Aug '01

15 Aug '01

"Wilfried Woeber, UniVie/ACOnet" wrote: > I think we were talking about increasing the size of a sTLA (when the > requirement for that can be documented), rather than allocating another > sTLA?! OK, my last mail was maybe a bit terse. Some background might help. We (KPNQwest, formerly EUnet) are a "supernational" registry. In the IPv4 world this is much like having 6 individual large registries with the corresponding number of open allocations that implies. Now, in the IPv6 world I'm told that we can't get an IPv6 sTLA for our direct backbone customers or for any of our other national networks because KPNQwest Finland (covered by the eu.eunet supernational registry) already has our one sub-TLA. Of course, that one sub-TLA gives us a total amount of address space which is adequate for our current requirements for the whole network but once this is split over each of about 20 separate autonomous systems, each with their own routing policy, this is hardly going to result in optimally aggregatable routing... James > Also, I seem to remember that the NCC reserves some space in the address > tree for that, so you might be able to obtain a "2nd" sTLA back-to-back > with the original one, which is equivalent to decreasing the prefix > length. > > I guess you would be free to structure that (combined/extended) address > space internally (for distribution to customers by more than one > operational unit). > > But probably I am missing something essential here. > > Wilfried. > ______________________________________________________________________ > > Of course, there would be at least one more sub-TLA allocated if the IPv4 > rules for supernational registries were to be applied to IPv6 instead of > restricting these to only having a single sub-TLA allocation... :-( > > James > > -- > James Aldridge, Senior Network Engineer (IP Architecture) > KPNQwest, Singel 540, 1017 AZ Amsterdam, NL > Tel: +31 70 379 37 03; GSM: +31 65 370 87 07 > > ----------------------------------------------------------------------------- --- > _________________________________:_____________________________________ > Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at > UniVie Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 > Universitaetsstrasse 7 : Fax: +43 1 4277 - 9 140 > A-1010 Vienna, Austria, Europe : RIPE-DB: WW144, PGP keyID 0xF0ACB369 > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > First things first, but not necessarily in that order....

3 2

WG: I-D ACTION:draft-engelstad-ngtrans-mipv4-over-mipv6-01.txt
by Thomas Trede 14 Aug '01

14 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: Montag, 13. August 2001 13:05 An: IETF-Announce: Cc: ngtrans(a)sunroof.eng.sun.com; ipng(a)sunroof.eng.sun.com; mobile-ip(a)sunroof.eng.sun.com Betreff: I-D ACTION:draft-engelstad-ngtrans-mipv4-over-mipv6-01.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Transitional Integration of Mobile IPv4 and Mobile IPv6 Author(s) : P. Engelstad Filename : draft-engelstad-ngtrans-mipv4-over-mipv6-01.txt Pages : 21 Date : 09-Aug-01 This draft outlines how a dual stack mobile node can be reached and communicate by means of both IPv4 and IPv6, even in situations where the mobile node is in reach of only either IPv4 or IPv6 networks. A Dual Stack Mobility Agent accommodates mobility and translates between IPv4 and IPv6 traffic. It may operate as a mobility agent in its own right or as a module that relays traffic between existing single stack Mobile IPv4 and Mobile IPv6 home agents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-engelstad-ngtrans-mipv4-over-mipv6 -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-engelstad-ngtrans-mipv4-over-mipv6-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-engelstad-ngtrans-mipv4-over-mipv6-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. ENCODING mime FILE /internet-drafts/draft-engelstad-ngtrans-mipv4-over-mipv6-01.txt

1 0

RE: 90 IPv6 sub-TLA allocations made
by stuart.prevost＠bt.com 13 Aug '01

13 Aug '01

David, Whilst I agree with what you are saying in that the RIPE community has identified issues, and that it is time to go into more detail to define a workable allocation policy. It would help if we had insight into what the 3 RIR thoughts are regarding these issues. I know that a new policy document will be published very shortly, and we should hopefully see what progress has been made towards a workable allocation policy. Personally I feel that it has taken far to long for a revised allocation policy to materialize, since review of the current document started in October 1999. Almost two years on we don't have new draft-policy we can even discuss let alone implement. Anyway I'll stop going on about it and look forward to reading the new draft :) Regards, Stuart > -----Original Message----- > From: David Kessens [mailto:david@IPRG.nokia.com] > Sent: Thursday, August 09, 2001 4:46 PM > To: BIDRON Alain BRX/DAP > Cc: Stephen Burley; lir-wg(a)ripe.net; ipv6-wg(a)ripe.net > Subject: Re: 90 IPv6 sub-TLA allocations made > > > > Alain, > > On Thu, Aug 09, 2001 at 04:45:24PM +0200, BIDRON Alain > BRX/DAP wrote: > > > > Do we really need to explore solutions again or do we need > a new Draft > > from the RIRs taking into account those proposals and the consensus > > expressed around, and able to be approved by the community ? > > I think that the problem description is quite clear. I think that it > is also clear that a majority of the people would like to have a > larger initial allocation. > > However, it is not clear how big such an allocation should be, whether > there should be a uniform size of the initial allocation, whether > multi-national registries should be able to get more than one > allocation etc. > > Next, we will also need to take a look at the definition of 80% > utilization, when people can come back to the regional registries for > more address space and how much address space they will get when they > come back and qualify for more address space. > > It's up to us as the RIPE community to identify these issues and to > advise the RIPE NCC on how to fix the current policy. So far, we have > done quite a good job in identifying the issues, it's now time to go > in more detail in order to define a workable allocation policy. > > David K. > --- >

1 0

RE: 90 IPv6 sub-TLA allocations made
by stuart.prevost＠bt.com 10 Aug '01

10 Aug '01

Sabrina, It would be nice if the new draft could be mailed to the relevant lists before the RIPE 40 meeting so people can have a meaningful discussion. Please can you indicate if/when a new version of the policy document will be published? Thanks, Stuart > -----Original Message----- > From: Sabrina Waschke [mailto:sabrina@ripe.net] > Sent: 09 August 2001 17:16 > To: James Aldridge > Cc: lir-wg(a)ripe.net; ipv6-wg(a)ripe.net > Subject: Re: 90 IPv6 sub-TLA allocations made > > > > James, > > Your request for a subsequent sub-TLA allocation was evaluated > according to the Provisional IPv6 Assignment and Allocation > Policy (4.2.5. Criteria for Subsequent Sub-TLA Allocations). > Please see: > > http://www.ripe.net/ipv6 > > As you know this policy is under revision and the current > discussions on these two mailing lists are encouraged. > > All three Regional Internet Registries receive input from their > communities and based on this a new draft of the policy document > will be presented at the upcoming RIPE 40 meeting in Prague. > > The presentation "IPv6 Bootstrap Phase" given at the last RIPE > meeting in Bologna can be found at: > > http://www.ripe.net/ripe/meetings/archive/ripe-39/presentation s/ipv6develop/ A Supernational Registry is a special case. You may want to use this presentation as a starting point to discuss the minimum allocation size. Kind regards, Sabrina Waschke -- o------------------------------------------o | Sabrina Waschke sabrina(a)ripe.net | | Registration Services Operations Manager | | | | RIPE NCC tel +31 20 535 4444 | | www.ripe.net fax +31 20 535 4445 | o------------------------------------------o

2 1

Re: 90 IPv6 sub-TLA allocations made
by Sabrina Waschke 10 Aug '01

10 Aug '01

James, Your request for a subsequent sub-TLA allocation was evaluated according to the Provisional IPv6 Assignment and Allocation Policy (4.2.5. Criteria for Subsequent Sub-TLA Allocations). Please see: http://www.ripe.net/ipv6 As you know this policy is under revision and the current discussions on these two mailing lists are encouraged. All three Regional Internet Registries receive input from their communities and based on this a new draft of the policy document will be presented at the upcoming RIPE 40 meeting in Prague. The presentation "IPv6 Bootstrap Phase" given at the last RIPE meeting in Bologna can be found at: http://www.ripe.net/ripe/meetings/archive/ripe-39/presentations/ipv6develop/ A Supernational Registry is a special case. You may want to use this presentation as a starting point to discuss the minimum allocation size. Kind regards, Sabrina Waschke -- o------------------------------------------o | Sabrina Waschke sabrina(a)ripe.net | | Registration Services Operations Manager | | | | RIPE NCC tel +31 20 535 4444 | | www.ripe.net fax +31 20 535 4445 | o------------------------------------------o

2 1

Re: 90 IPv6 sub-TLA allocations made
by David Kessens 09 Aug '01

09 Aug '01

Alain, On Thu, Aug 09, 2001 at 04:45:24PM +0200, BIDRON Alain BRX/DAP wrote: > > Do we really need to explore solutions again or do we need a new Draft > from the RIRs taking into account those proposals and the consensus > expressed around, and able to be approved by the community ? I think that the problem description is quite clear. I think that it is also clear that a majority of the people would like to have a larger initial allocation. However, it is not clear how big such an allocation should be, whether there should be a uniform size of the initial allocation, whether multi-national registries should be able to get more than one allocation etc. Next, we will also need to take a look at the definition of 80% utilization, when people can come back to the regional registries for more address space and how much address space they will get when they come back and qualify for more address space. It's up to us as the RIPE community to identify these issues and to advise the RIPE NCC on how to fix the current policy. So far, we have done quite a good job in identifying the issues, it's now time to go in more detail in order to define a workable allocation policy. David K. ---

1 0

Re: 90 IPv6 sub-TLA allocations made
by James Aldridge 08 Aug '01

08 Aug '01

David R Huberman wrote: > > > Of course, that one sub-TLA gives us a total amount of address space which is > > adequate for our current requirements for the whole network but once this i s > > split over each of about 20 separate autonomous systems, each with their ow n > > routing policy, this is hardly going to result in optimally aggregatable > > routing... > > And when you explain this to RIPE, how do they respond? If you can make a > bona fide engineering argument for obtaining more than one sub-TLA, it > seems to me that any RIR is obliged to seriously consider that argument. The last reply from the RIPE NCC hostmasters said, "Because Supernational Registries may not receive multiple IPv6 allocations you would need to have allocated 80% of the networks in your current sTLA before we could issue more address space." So we can have a /35 fragmented among something like 20 different networks but can't get any additional address space until 80% of the current /35 is used. James -- James Aldridge, Senior Network Engineer (IP Architecture) KPNQwest, Singel 540, 1017 AZ Amsterdam, NL Tel: +31 70 379 37 03; GSM: +31 65 370 87 07

2 2

Re: 90 IPv6 sub-TLA allocations made
by David R Huberman 08 Aug '01

08 Aug '01

To: lists-lir-wg-out(a)lists.ripe.net To: postmaster1(a)wplus.net To: lists-lir-wg-out(a)lists.ripe.net To: postmaster1(a)wplus.net To: lists-lir-wg-out(a)lists.ripe.net To: postmaster1(a)wplus.net To: lists-lir-wg-out(a)lists.ripe.net To: postmaster1(a)wplus.net To: lists-lir-wg-out(a)lists.ripe.net To: James Aldridge <jhma(a)KPNQwest.net> Reply-To: <E15UUhh-0001m9-00(a)aegir.EU.net> > The last reply from the RIPE NCC hostmasters said, "Because Supernational > Registries may not receive multiple IPv6 allocations you would need to have > allocated 80% of the networks in your current sTLA before we could issue more > address space." Please forgive my ignorance and allow me to ask, "where is it written that Supernational Registries may not receive multiple sub-TLAs?" Is this a RIPE NCC interpretation of the bootstrap criteria or is it actually written down somewhere? /david

1 0

90 IPv6 sub-TLA allocations made
by leo vegoda 06 Aug '01

06 Aug '01

Dear Colleagues, In 1999 The RIPE NCC and the other Regional Internet Registries (RIRs), ARIN and APNIC, began allocating IPv6 sub-TLAs. According to current policy[1] the bootstrap phase "will only apply until 100 requesting organisations have received allocations of sub-TLA address space". To date, the three RIRs have made 90 sub-TLA allocations[2]. At RIPE 39 in Bologna it was suggested to prolong the bootstrap phase until RIPE 40 if 100 allocations are reached. We will inform the community as soon as 100 IPv6 allocations have been made. Other IPv6 information is available on our web site at <http://www.ripe.net/ipv6>. Regards, -- leo vegoda Senior Hostmaster RIPE NCC [1] The Global Provisional IPv6 Assignment and Allocation Policy document is available at <http://www.ripe.net/ripe/docs/ipv6policy.html> [2] Details of the allocations are available from the IPv6 section at <http://www.ripe.net/cgi-bin/ipv6allocs>.

2 1

WG: I-D ACTION:draft-ietf-ipngwg-icmp-name-lookups-08.txt
by Thomas Trede 03 Aug '01

03 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: Mittwoch, 25. Juli 2001 12:32 An: IETF-Announce: Cc: ipng(a)sunroof.eng.sun.com Betreff: I-D ACTION:draft-ietf-ipngwg-icmp-name-lookups-08.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 Node Information Queries Author(s) : M. Crawford Filename : draft-ietf-ipngwg-icmp-name-lookups-08.txt Pages : 15 Date : 24-Jul-01 This document describes a protocol for asking an IPv6 node to supply certain network information, such as its hostname or fully-qualified domain name. IPv6 implementation experience has shown that direct queries for a hostname are useful, and a direct query mechanism for other information has been found useful in serverless environments and for debugging. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-icmp-name-lookups-08.t xt 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-icmp-name-lookups-08.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-icmp-name-lookups-08.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-ietf-ipngwg-icmp-name-lookups-08.txt

1 0

WG: Last Call: Unicast-Prefix-based IPv6 Multicast Addresses to Proposed Standard
by Thomas Trede 03 Aug '01

03 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 The IESG Gesendet: Mittwoch, 25. Juli 2001 20:12 An: IETF-Announce: Cc: ipng(a)sunroof.eng.sun.com; malloc(a)catarina.usc.edu Betreff: Last Call: Unicast-Prefix-based IPv6 Multicast Addresses to Proposed Standard The IESG has received a request from the IPNG and the MALLOC Working Groups to consider publication of the folloing two Interent-Drafts as Proposed Standards. o Unicast-Prefix-based IPv6 Multicast Addresses <draft-ietf-ipngwg-uni-based-mcast-02.txt> o Dynamic Allocation Guidelines for IPv6 Multicast Addresses <draft-ietf-malloc-ipv6-guide-03.txt> as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg(a)ietf.org or ietf(a)ietf.org mailing lists by August 25, 2001. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-uni-based-mcast-02.txt http://www.ietf.org/internet-drafts/<draft-ietf-malloc-ipv6-guide-03.txt -------------------------------------------------------------------- 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: I-D ACTION:draft-ietf-ipngwg-default-addr-select-05.txt
by Thomas Trede 03 Aug '01

03 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: Freitag, 27. Juli 2001 13:08 An: IETF-Announce: Cc: ipng(a)sunroof.eng.sun.com Betreff: I-D ACTION:draft-ietf-ipngwg-default-addr-select-05.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 : Default Address Selection for IPv6 Author(s) : R. Draves Filename : draft-ietf-ipngwg-default-addr-select-05.txt Pages : 21 Date : 26-Jul-01 This document describes two algorithms, for source address selection and for destination address selection. The algorithms specify default behavior for all IPv6 implementations. They do not override choices made by applications or upper-layer protocols, nor do they preclude the development of more advanced mechanisms for address selection. The two algorithms share a common framework, including an optional mechanism for allowing administrators to provide policy that can override the default behavior. In dual stack implementations, the framework allows the destination address selection algorithm to consider both IPv4 and IPv6 addresses - depending on the available source addresses, the algorithm might prefer IPv6 addresses over IPv4 addresses, or vice-versa. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-default-addr-select-05 .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-default-addr-select-05.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-default-addr-select-05.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-ietf-ipngwg-default-addr-select-05.txt

1 0

WG: I-D ACTION:draft-ietf-ipngwg-icmp-v3-01.txt
by Thomas Trede 03 Aug '01

03 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: Dienstag, 24. Juli 2001 12:29 An: IETF-Announce: Cc: ipng(a)sunroof.eng.sun.com Betreff: I-D ACTION:draft-ietf-ipngwg-icmp-v3-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 : Internet Control Message Protocol (ICMPv6)for the Internet Protocol Version 6 (IPv6) Specification Author(s) : A. Conta, S. Deering Filename : draft-ietf-ipngwg-icmp-v3-01.txt Pages : 20 Date : 23-Jul-01 This document specifies a set of Internet Control Message Protocol (ICMP) messages for use with version 6 of the Internet Protocol (IPv6). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-icmp-v3-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-icmp-v3-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-icmp-v3-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. ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-icmp-v3-01.txt

1 0

WG: Protocol Action: Transmission of IPv6 Packets over IEEE 1394 Networks to Proposed Standard
by Thomas Trede 01 Aug '01

01 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 The IESG Gesendet: Mittwoch, 1. August 2001 01:50 An: IETF-Announce: Cc: RFC Editor; IANA; Internet Architecture Board; ipng(a)sunroof.eng.sun.com Betreff: Protocol Action: Transmission of IPv6 Packets over IEEE 1394 Networks to Proposed Standard The IESG has approved the Internet-Draft 'Transmission of IPv6 Packets over IEEE 1394 Networks' <draft-ietf-ipngwg-1394-02.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 IEEE Std 1394-1995 is a standard for a High Performance Serial Bus. This document describes the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on IEEE1394 networks. It also describes the content of the Source/Target Link-layer Address option used in Neighbor Discovery to perform address resolution when the messages are transmitted on an IEEE1394 network. Working Group Summary This document is based heavily on the IPv4 over 1394 specification [RFC 2734] and defers to that specification for the definition of some of its functions. During the Last Call, comments were made that there may be performance problems with the existing IPv4 over 1394 specification and that it may need to be reexamined. Consequently, requests to delay advancement of this document were made. However, at this time, it remains unclear whether and when the IPv4 over 1394 standard will be updated and to what extent such an update will obsolete the current design. Thus, the IESG has approved this document as a Proposed Standard. Like all Proposed Standards, it can be updated at anytime as needed. Protocol Quality This specification has been reviewed for the IESG by Thomas Narten. -------------------------------------------------------------------- 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