- ipv6-wg - mailman.ripe.net

Fw: SVRLOC WG last call: draft-ietf-svrloc-ipv6-09.txt
by Thomas Trede 09 Jul '00

09 Jul '00

FYI. Regards, Thomas Trede ----- Original Message ----- From: "Erik Guttman" <Erik.Guttman(a)germany.sun.com> To: <srvloc(a)srvloc.org>; <ipng(a)sunroof.eng.sun.com> Cc: <erik.guttman(a)germany.sun.com> Sent: Friday, July 07, 2000 1:33 PM Subject: SVRLOC WG last call: draft-ietf-svrloc-ipv6-09.txt > > The following specification is in working group last call: > > Service Location Protocol Modifications for IPv6 > draft-ietf-svrloc-ipv6-09.txt > > Please send comments before July 21, 2000. > > Of interest are rules which prevent the locations of services > from being discovered where they cannot be reached. For > example, a service with a link-local scope address can only be > discovered on the same link. > > Since the specification concerns IPv6, the WG last call notice > has been sent to the IPng list. Please reply to the SVRLOC WG > list. > > Erik Guttman > SVRLOC WG Chair > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo(a)sunroof.eng.sun.com > -------------------------------------------------------------------- >

1 0

Fw: KAME stable 20000704
by Thomas Trede 07 Jul '00

07 Jul '00

FYI. Regards, Thomas Trede ----- Original Message ----- From: <core(a)kame.net> To: <ipng(a)sunroof.eng.sun.com> Sent: Thursday, July 06, 2000 8:15 AM Subject: KAME stable 20000704 > As usual, KAME Project has released "stable" packages of IPv6/IPsec > network code for the following BSD variants. > > --- > bsdi3 BSDI BSD/OS http://www.bsdi.com/ > kernel: BSD/OS 3.1 patchlevel 0 > userland: BSD/OS 3.0 patchlevel 0 > include: BSD/OS 3.0 patchlevel 0 + ISC BIND 4.9.7 > bsdi4 BSDI BSD/OS 4.1 patchlevel 0 http://www.bsdi.com/ > freebsd2 FreeBSD 2.2.8-RELEASE http://www.freebsd.org/ > freebsd3 FreeBSD 3.4-RELEASE http://www.freebsd.org/ > netbsd NetBSD 1.4.2 http://www.netbsd.org/ > openbsd OpenBSD 2.7 http://www.openbsd.org/ > --- > > Note: {Free,Net,Open}BSD-current have already merged the KAME source > code, from *past* versions of KAME codebase. For differences between > KAME kits and *BSD tree, please visit: > http://www.kame.net/project-overview.html#release > http://www.kame.net/dev/cvsweb.cgi/kame/COVERAGE > > They are free of charge but absolutely no warranty. They are avaiable > from the following web site: > > http://www.kame.net/ > > To know the changes from the previous stable package, please refer to > the CHANGELOG/RELNOTES file. > > --KAME Project > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo(a)sunroof.eng.sun.com > -------------------------------------------------------------------- >

1 0

Fw: I-D ACTION:draft-ietf-ipngwg-scopedaddr-format-02.txt
by Thomas Trede 30 Jun '00

30 Jun '00

FYI. Regards, Thomas Trede ----- Original Message ----- From: <Internet-Drafts(a)ietf.org> To: <IETF-Announce: ;> Cc: <ipng(a)sunroof.eng.sun.com> Sent: Thursday, June 29, 2000 12:46 PM Subject: I-D ACTION:draft-ietf-ipngwg-scopedaddr-format-02.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 : An Extension of Format for IPv6 Scoped Addresses > Author(s) : T. Jinmei, A. Onoe > Filename : draft-ietf-ipngwg-scopedaddr-format-02.txt > Pages : 11 > Date : 28-Jun-00 > > This document defines an extension of the format for IPv6 scoped > addresses. In the format, a scope identifier is attached to a scoped > address in order to supplement the ambiguity of the semantics of > the address. Using the format with some library routines will make > scope-aware applications simpler. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-scopedaddr-format-02.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-scopedaddr-format-02.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-scopedaddr-format-02.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. >

1 0

Fw: Protocol Action: Router Renumbering for IPv6 to Proposed Standard
by Thomas Trede 30 Jun '00

30 Jun '00

FYI. Regards, Thomas Trede ----- Original Message ----- From: "The IESG" <iesg-secretary(a)ietf.org> To: <IETF-Announce: ;> Cc: "RFC Editor" <rfc-editor(a)isi.edu>; "Internet Architecture Board" <iab(a)isi.edu>; <ipng(a)sunroof.eng.sun.com> Sent: Friday, June 30, 2000 1:14 PM Subject: Protocol Action: Router Renumbering for IPv6 to Proposed Standard > > > The IESG has approved the Internet-Draft 'Router Renumbering for IPv6' > <draft-ietf-ipngwg-router-renum-10.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 > > IPv6 Neighbor Discovery and Address Autoconfiguration conveniently > make initial assignments of address prefixes to hosts. Hosts obtain > routing prefixes from routers, and form addresses from those > prefixes. This mechanism simplifies site renumbering by allowing > routers to simultaneously phase in new prefixes and phase out old ones. > > This document defines a mechanism called Router Renumbering that > allows the address prefixes routers advertise to be configured and > reconfigured from a central place. That is, it allows a site > administer to easily change the prefixes that all of its routers > advertise. This mechanism may facilitate easier site renumbering. > > Working Group Summary > > The IPng WG originally asked to advance the document over a year ago, > and the IESG returned it to the WG asking for a strengthening of the > reliability aspects of the protocol. This version of the document > includes those changes and no issues were raised during the Last Call. > > Protocol Quality > > This protocol has been reviewed for the IESG by Thomas Narten and Erik > Nordmark. > > Note to RFC Editor: > > Please include the following as an IESG Note: > > This document defines mechanisms for informing a set of routers of > renumbering operations they are to perform, including a mode of > operation in environments in which the exact number of routers is > unknown. Reliably informing all routers when the actual number of > routers is unknown is a difficult problem. Implementation and > operational experience will be needed to fully understand the > applicabilty and scalability aspects of the mechanisms defined in > this document when the number of routers is unknown. > > -------------------------------------------------------------------- > 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

draft ipv6 wg minutes RIPE 36
by David Kessens 30 Jun '00

30 Jun '00

Hi, Please see below for the minutes of the ipv6 working group session at RIPE 36. I would appreciate your input for corrections, comments or additions. The minutes will be declared final in two weeks if no comments besides typos and small corrections are received within the next two weeks, otherwise we will revise the draft and open a new period of comments. Taking the minutes is not an easy task so I would specifically like to thank Jeroen Bet from the RIPE NCC for taking the minutes. I would also like to take the chance to bring your attention to an agenda topic that we didn't have the chance to discuss: 'I. Input for the 2001 activity plan of the RIPE NCC'. If you have suggestions or ideas, don't hesitate to send them to the list and/or the board of the RIPE NCC. David K. --- 1st draft on minutes from the IPv6 working group Budapest 20000523 RIPE Meeting: 36 Working Group: IPv6 Status: 1st Draft Budapest 20000517 IPv6 Working Group Chair: David Kessens Scribe: Jeroen Bet A. Administrative stuff - Appointment of scribe - Agenda bashing B. Status of 6bone (David Kessens) C. A presentation from the Ipv6 EVENT in Birmingham (UK) 20000510 by (Stuart Prevost) D. News from the IPv6 forum and meeting in Telluride (Juergen Rauschenbach) E. Status of IPv6 Allocation Guideline draft (Joao) F. European developments/initiatives regarding IPv6 (input from the audience) G. Reports on on-going projects, success & failures stories on IPv6 H. Future plans for the working group I. Input for the 2001 activisty plan of the RIPE NCC Z. AOB Action points from RIPE 35: NONE New action points from RIPE 36: on the chair to summarize the discussion and to collect more advise and post it to the IPv6 mailing list. A. Administrative stuff - Jeroen Bet was appointed scribe - Agenda was approved with one addition: A presentation from the Ipv6 EVENT in Birmingham (UK) 20000510 by Stuart Prevost under C. B. Status of 6bone http://www.kessens.com/~david/presentations/ David Kessens: The number of sites, allocations have all increased since 20000222. There are now 46 countries represented in 6BONE (was 42). The number of Queries have been once again decreased due to the database downloads by members. C. A presentation from the Ipv6 EVENT in Birmingham (UK) 20000510 http://www.ipv6forum.com/navbar/events/birmingham00/presentations/ Stuart Prevost The IPv6 FORUM event in Birmingham, UK was organised by BT and sponsored by Cisco. It was an overall promotion day for IPv6. The key speakers were Chris Earnshaw (BT) who had a presentation called "The new wave ISP" where he pleaded that ISP's should upgrade now, because the longer the upgrade to IPv6 is postponed, the costlier it will be. Another presentation was by Peter Kirstein (University College London) on the "new Internet" and Mario Campolargo (Head of research Networks - -European Commission) had a presentation on European Strategic Initiatives. The key point here was that the demand for IPv6 has to be there, you can't just say from now on we will use IPv6. Several projects were supported and initiated by the European Commission to promote IPv6. There were several more presentations (Nokia, Ericsson, Telia and others)in Birmingham. More information about the event including the presentations is located at: D. News from the IPv6 forum and meeting in Telluride http://www.ipv6forum.com/ http://www.ipv6forum.com/navbar/events/telluride00/presentations/ (Juergen Rauschenbach) The IPv6 forum has 5 new members, 2 from the US, 2 from the Asia Pacific region and 1 from Europe. A list of members is located at: A 2 day conference was held in Telluride (US) which included a one day tutorial by Florent Parent and Regis Desmeules, Viagenie. Judy Estrin, CTO and Senior Vice President, Cisco Systems gave a presentation which called for *integration* of IPv6 not a *transition*. Furthermore various vendors announced upgrades and new releases of their products which are now compatible with IPv6. will give you an overview of all the presentations during the summit. There are also MP3 files of the key speeches as well as a PDF file of the IPv6 tutorial. The next big IPv6 thing is in London in June, and there is a summit in Japan coming up at the end of the year. Also from November 29th until December 1st there is a 3 day conference on IPv6 in Madrid. E. Status of IPv6 Allocation Guideline draft (Joao) A discussion started following the discussions at the IETF meeting held in Adelaide, especially on whether to use /48s, /56s, or /64s for end-users. One of the obvious problems is the definition of an end-user itself. The issue was raised in the ARIN meeting in Calgary (20000403). The question popped up which direction to take? Should we conserve address-space as much as possible or should we give end-users a little more addresses to make it easier from an administrative point of view. Bill Manning pointed out that these were early days in the IPv6 world, so should we decide on this issue now? Gert Doering brought up the issue of administrative ease. If we issue a /56, it will be easier for ISP's. A lot of people felt that being a bit more flexible is ok but we shouldn't be too flexible. Stephen Burley said that giving an end-user more than what they needed could create complications later on. Some people felt that a /64 was too small but a /48 was too big for an end-user so a /56 would be a good compromise. Wilfried Woeber: we should be cautious about re-shuffling policies. IPv6 is overall more interesting for large networks. Having 8 bits for subnets is not enough. Giving a /64 to any end user that is not big enough to qualify for a /48 could cause problems. Someone pointed out why there was a need to use fixed boundaries when we all use CIDR. David Kessens concluded from the arguments that the attendees brought up that a /64 is not enough as a default assignment. If a LIR issues a /56 or /48 for a default would this be reasonable? Again there was no consensus over this. As the issue of /64 vs. /56 was brought up in the IETF meeting in Adelaide, people started wondering why the IETF is so terrified of giving all end-users 'only' a /64? It seems that the IETF doesn't want NAT to be used with IPv6. Also subnetting and bridging in a /64 is highly undesirable. Giving them a /56 will give end-users the incentive not to do this. Paul Wilson: There is no engineering reason to select a /48 opposed to a /56. a /48 is big enough for any site. However a /48 is way too big for a dial up account -> give them a /64. LIR's should give a /64 for mobile phones, enough for one subnet. There would be no reason for assigning more than a /56 for home use. Assign any length that a user needs in the foreseeable future. We assume a home site will have one provider but every household will have many side addresses. This so far seems not to be anticipated. IPv6 will have to last forever, so do not throw away address-space. Is a floating boundary preferred? Some attendees said yes. It will initiate the end-users thinking process of how much they actually need. It is the ISP's decision of how much address-space to give to an end-user. In fact this would be the same principle that we use for IPv4. There was no consensus over a floating boundary. A question came up what the community will do with the bits we save in the SLA space. What happens if an ISP runs out of space? The question was left unanswered. - -> ACTION on the chair to summarize the discussion and to collect more advise and post it to the IPv6 mailing list. David Kessens concluded that we need to find a balance between conservation and administrative flexibility. F. European developments/initiatives regarding IPv6 topic was skipped because of lack of time G. Reports on on-going projects, success & failures stories on IPv6 topic was skipped because of lack of time H. Future plans for the working group topic was skipped because of lack of time I. Input for the 2001 activisty plan of the RIPE NCC topic was skipped because of lack of time Z. AOB Bernhard Tuy and Laurent Toutain invited all the attendees to the IPv6 platform demonstration in the terminal room set up by Bernhard Tuy, Q: Should we set up a global mailing list for IPv6 issues? There are several now in various regions and it might be an idea to coordinate this. Especially for the discussion about the size of the assignments. 17.00 The meeting was closed

1 0

Fw: I-D ACTION:draft-ietf-ipngwg-ipv6-2260-00.txt
by Thomas Trede 27 Jun '00

27 Jun '00

FYI. Regards, Thomas Trede ----- Original Message ----- From: <Internet-Drafts(a)ietf.org> To: <IETF-Announce: ;> Cc: <ipng(a)sunroof.eng.sun.com> Sent: Tuesday, June 27, 2000 12:44 PM Subject: I-D ACTION:draft-ietf-ipngwg-ipv6-2260-00.txt > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IPNG Working Group of the IETF. > > Title : IPv6 multihoming support at site exit routers > Author(s) : J. Hagino > Filename : draft-ietf-ipngwg-ipv6-2260-00.txt > Pages : 9 > Date : 26-Jun-00 > > The document describes a mechanism for basic IPv6 multihoming support, > and its operational requirements. The mechanism can be combined with > more sophisticated (or complex) multihoming support mechanisms, and can > be used as a foundation for other mechanisms. The document is largely > based on RFC2260 [Bates, 1998] by Tony Bates. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-ipv6-2260-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-ietf-ipngwg-ipv6-2260-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-ietf-ipngwg-ipv6-2260-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. >

1 0

Fw: W.G. Last Call on "IPv6 Multihoming with Route Aggregation"
by Thomas Trede 25 Jun '00

25 Jun '00

FYI. Regards, Thomas Trede ----- Original Message ----- From: "Bob Hinden" <hinden(a)iprg.nokia.com> To: <ipng(a)sunroof.eng.sun.com> Sent: Saturday, June 24, 2000 1:20 AM Subject: W.G. Last Call on "IPv6 Multihoming with Route Aggregation" > This is a IPng working group last call for comments on advancing the > following document as Informational: > > Title : IPv6 Multihoming with Route Aggregation > Author(s) : J. Yu > Filename : draft-ietf-ipngwg-ipv6multihome-with-aggr-00.txt > Pages : 7 > Date : 24-Nov-99 > > 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 July 7, 2000. > > 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

Fw: Revised IPng Working Group Charter
by Thomas Trede 25 Jun '00

25 Jun '00

FYI. Regards, Thomas Trede ----- Original Message ----- From: "Bob Hinden" <hinden(a)iprg.nokia.com> To: <ipng(a)sunroof.eng.sun.com> Cc: <hinden(a)iprg.nokia.com>; <deering(a)cisco.com> Sent: Friday, June 23, 2000 11:34 PM Subject: Revised IPng Working Group Charter > Folks, > > Attached is a draft of a revised charter for the working group. Updating > the charter was agreed to at the Grenoble and Minneapolis working group > meetings, but it took the chairs and AD's a while to draft a new one. > > The charter includes changing the name of the working group to the "IP > Version 6 Working Group", but will keep the acronym of "ipngwg". This will > avoid having to rename all current internet drafts. > > Please send comments on the new charter to the mailing list. There will be > a short session in Pittsburgh to discuss it as well. > > Bob Hinden / Steve Deering > > -------------------------------------------------------------------------- --- > Draft - Draft - Draft - Draft - Draft - Draft - Draft - Draft - Draft - Draft > -------------------------------------------------------------------------- --- > > IP Version 6 Working Group (ipngwg) *** note: change of name but not acronym > > Chair(s): > > Bob Hinden <hinden(a)iprg.nokia.com> > Steve Deering <deering(a)cisco.com> > > Document Editor > > Bob Hinden (hinden(a)iprg.nokia.com) > > Internet Area Director(s): > > Thomas Narten <narten(a)raleigh.ibm.com> > Erik Nordmark <nordmark(a)eng.sun.com> > > Internet Area Advisor: > > Thomas Narten <narten(a)raleigh.ibm.com> > > Mailing Lists: > > General Discussion:ipng@sunroof.eng.sun.com > To Subscribe: majordomo(a)sunroof.eng.sun.com > In Body: in body: subscribe ipng > Archive: ftp://playground.sun.com/pub/ipng/mail-archive > > Description of Working Group: > > IP version 6 or IPv6 (also formerly known as IP Next Generation or IPng) > is intended to support the continued growth of the Internet, both in > size and capabilities, by offering a greatly increased IP address space > and other enhancements over IPv4. The working group was originally > chartered to implement the recommendations of the IPng Area Directors > as outlined at the July 1994 IETF meeting and in "The Recommendation > for the IP Next Generation Protocol," RFC1752, January 1995. Most of > the tasks in that original charter have been completed, and the core > IPv6 protocol specifications are now on the IETF standards track. > The working group's ongoing responsibilities are as follows: > > - Complete work from the original charter and follow-on work, as > outlined below. > > - Keep all IPv6 working group documents moving along publication / > standardization track. > > - Serve as a review board and body of competence and coordination for > IPv6 architectural issues that span multiple IETF working groups. > > - Provide a home for IPv6-related work that doesn't fit in an existing > IETF working group and doesn't merit a working group of its own. > > - Provide technical input to ICANN, Internet Address Registries, and > IANA with regard to IPv6 address allocation policies and procedures. > > - Provide technical input and review to IANA with regard to IPv6 > protocol and parameter assignments. > > The list of the working group's current work items is as follows: > > - Revise ICMPv6 spec (scope-exceeded err, no error to redirect, > editorial) > - Revise Generic Tunneling spec (add bidirectional tunnels) > - Update Basic and Advanced API specs > - Complete Router Renumbering spec > - Complete Scoped Address Architecture spec and any necessary revisions > to other working group drafts required to properly implement support > for IPv6 address scoping > - Complete work on recommended address-selection algorithms > - Work on new solutions to site-multihoming problems, possibly including > both host-based and router-based solutions. > - Complete work on local IPv6 networking as part of IPv6 plug-and-play > - Complete work on privacy extensions to stateless address configuration > - Document IPv6 renumbering model > - Complete the GSE Analysis document > - Complete the Inverse Neighbor Discovery spec > - Complete the IPv6 Node Information Queries spec > - Complete MIB specs as required by any working group protocol specs > > New work items not listed above require the approval of the working > group and Internet Area directors before they will be taken on by the > working group. > > The working group would welcome contributions on the following topics > (this is not an exhaustive list): > > - Flow label standardization > - Solutions to other multihoming issues, beyond those specific to > site-multihoming > - Integration of autoconfiguration, mobility, DNS, service discovery > and other technologies to enhance IPv6 plug-and-play > - IPv6 dial-up issues relating to address assignment, use of Neighbor > Discovery, etc. (not including AAA work) > - Specifications for IPv6 over additional media > - Extending MLD to include functionality of IGMPv3 > - Host use of anycast; TCP use of anycast > - Support for multi-link subnets (single subnet spans multiple links) > - Scope-name discovery > - IPv6 protocol extensions to accommodate mobile wireless networks. > > Goals and Milestones: > > Aug 2000 Complete MLD MIB and submit for Proposed Standard > > Aug 2000 Complete privacy extensions specification and submit for > Proposed Standard > > Aug 2000 Completed revision of GSE Analysis document and resubmit > for Informational > > Aug 2000 Complete the Inverse Neighbor Discovery specification > and submit for Proposed Standard > > Aug 2000 Complete IPv6 Multihoming with Route Aggregation and submit > for Informational. > > Oct 2000 Update ICMP document and resubmit for Draft Standard > > Oct 2000 Update Generic Tunneling specification and resubmit for > Proposed Standard > > Oct 2000 Complete updates to Basic and Advanced API specifications > and submit for Informational > > Dec 2000 Complete Scoped Address Architecture and submit for Proposed > Standard > > Dec 2000 Compete Address Selection specification and submit for Proposed > Standard > > Dec 2000 Complete Local IPv6 Networking Specification and submit for > Proposed Standard > > Dec 2000 Complete the IPv6 Node Information Queries specification > and submit for Proposed Standard > > Mar 2001 Complete IPv6 renumbering model document and submit for > Informational > > -------------------------------------------------------------------------- --- > Draft - Draft - Draft - Draft - Draft - Draft - Draft - Draft - Draft - Draft > -------------------------------------------------------------------------- --- > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo(a)sunroof.eng.sun.com > -------------------------------------------------------------------- >

1 0

Fw: W.G. Last Call on "Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification"
by Thomas Trede 23 Jun '00

23 Jun '00

FYI. Regards, Thomas Trede ----- Original Message ----- From: "Bob Hinden" <hinden(a)iprg.nokia.com> To: <ipng(a)sunroof.eng.sun.com> Sent: Friday, June 23, 2000 1:04 AM Subject: Re: W.G. Last Call on "Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification" > The author of this draft's email address has changed. His new address is: > > aconta(a)txc.com > > Bob > > At 01:35 PM 6/22/2000 -0700, Bob Hinden wrote: > >I forgot to add that this document is now an IPng w.g. document. We > >inherited it when the ION w.g. concluded. > > > >Bob > > > >At 01:26 PM 6/22/2000 -0700, Bob Hinden wrote: > >>This is a IPng working group last call for comments on advancing the > >>following document as a Proposed Standard: > >> > >> Title : Extensions to IPv6 Neighbor Discovery for Inverse > >> Discovery Specification > >> Author(s) : A. Conta > >> Filename : draft-ietf-ion-ipv6-ind-03.txt > >> Pages : 22 > >> Date : 27-Oct-99 > >> > >>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 July 6, 2000. > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo(a)sunroof.eng.sun.com > -------------------------------------------------------------------- >

1 0

Fw: W.G. Last Call on "Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification"
by Thomas Trede 23 Jun '00

23 Jun '00

FYI. Regards, Thomas Trede ----- Original Message ----- From: "Bob Hinden" <hinden(a)iprg.nokia.com> To: <ipng(a)sunroof.eng.sun.com> Sent: Thursday, June 22, 2000 10:35 PM Subject: Re: W.G. Last Call on "Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification" > I forgot to add that this document is now an IPng w.g. document. We > inherited it when the ION w.g. concluded. > > Bob > > At 01:26 PM 6/22/2000 -0700, Bob Hinden wrote: > >This is a IPng working group last call for comments on advancing the > >following document as a Proposed Standard: > > > > Title : Extensions to IPv6 Neighbor Discovery for Inverse > > Discovery Specification > > Author(s) : A. Conta > > Filename : draft-ietf-ion-ipv6-ind-03.txt > > Pages : 22 > > Date : 27-Oct-99 > > > >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 July 6, 2000. > > > >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