- ipv6-wg - mailman.ripe.net

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