July 2000 - ipv6-wg - mailman.ripe.net

Fw: New "IP Version 6 Addressing Architecture" draft
by Thomas Trede 15 Jul '00

15 Jul '00

FYI. Regards, Thomas Trede ----- Original Message ----- From: "Bob Hinden" <hinden(a)iprg.nokia.com> To: <ipng(a)sunroof.eng.sun.com> Sent: Thursday, July 13, 2000 11:25 PM Subject: New "IP Version 6 Addressing Architecture" draft > I just submitted a new version of "IP Version 6 Addressing Architecture" to > be an internet draft. Until is available in the ID directories it can be > found at: > > ftp://playground.sun.com/pub/hinden/draft-ietf-ipngwg-addr-arch-v3-01.txt > > The changes in this draft resolve issues raised in the w.g. last call for > Draft Standard, removed the appendix defining ABNF description of text > representations because it was not correct, and unassigning the IPX address > block because there does not appear to be any current or planned usage. > > Overall the changes from RFC2373 are: > > - Removed the ABNF Description of Text Representations Appendix. > - Changed the address block reserved for IPX addresses to > unassigned. > - Multicast scope name changes: > o Changed name of scope value 1 from "node-local" to > "interface-local" > o Reserved scope value 3 for "subnet-local" for multi-link > subnets > o Defined scope value 4 as "admin-local" > - Clarified text describing Exchanges. > - Corrected reference to RFC1933 and updated references. > - Several minor textual clarifications. > > Once the new draft is out, it will be sent to the IESG for Draft > Standard. This document will replace RFC2373. > > Bob > > -------------------------------------------------------------------- > 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-ion-ipv6-ind-04.txt
by Thomas Trede 15 Jul '00

15 Jul '00

FYI. Regards, Thomas Trede ----- Original Message ----- From: <Internet-Drafts(a)ietf.org> To: <IETF-Announce: ;> Cc: <ipng(a)sunroof.eng.sun.com> Sent: Friday, July 14, 2000 12:50 PM Subject: I-D ACTION:draft-ietf-ion-ipv6-ind-04.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 : Extensions to IPv6 Neighbor Discovery for Inverse > Discovery Specification > Author(s) : A. Conta > Filename : draft-ietf-ion-ipv6-ind-04.txt > Pages : 21 > Date : 13-Jul-00 > > This memo describes extensions to the IPv6 Neighbor Discovery that > allow a node to solicit and be advertised an IPv6 address > corresponding to a given link-layer address. These extensions are > called Inverse Neighbor Discovery. They specifically apply to Frame > Relay networks but they may also apply to other networks with similar > behavior. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ion-ipv6-ind-04.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-ion-ipv6-ind-04.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-ion-ipv6-ind-04.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

RE: (ngtrans) IPv6 Policy Document Revision suggestion
by george.tsirtsis＠bt.com 13 Jul '00

13 Jul '00

Just to complement Stuart's position > -----Original Message----- > From: stuart.prevost(a)bt.com [SMTP:stuart.prevost@bt.com] > Sent: Thursday, July 13, 2000 3:48 PM > To: ngtrans(a)sunroof.eng.sun.com; ipv6-wg(a)ripe.net; mir(a)ripe.net; > ipng(a)sunroof.eng.sun.com; sig-ipv6(a)apnic.net; richardj(a)arin.net; > Daniel.Karrenberg(a)ripe.net; joao(a)ripe.net > Subject: (ngtrans) IPv6 Policy Document Revision suggestion > From reading all the emails it seems that the /48 approach as the *minimum* allocation is the way the IETF would like IPv6 deployment to proceed. However, as it has been demonstrated, the /35 allocations today would only allow for 8,192 /48 per subTLA, and this is assuming that the subTLA holder hasn't split up the NLA block so they can allocate to other providers, in which case this figure could be as small as 256 or lower!!!! > I see this as the reason why ISPs consider /48 for a home customer > as too large, and hence the sliding-window & /56 discussion at the last > RIPE > meeting. > > Note that we recognise the benefits of /48 for multihoming/rehomeing and maybe more importantly to make sure that IPv6 NAT will *never* become a reality! Thus, as an ISP, we support /48 allocations if can be confident that we can get enough of them; i.e.: we get /29s instead of /35s. > Now, if the /48 allocation is the way to proceed, I feel that all > initial /35 allocations should be initially changed to /29 as the first > step. This can be done easily as all allocations have the /29 reserved to > ensure a contiguous block. However a /29 allows for 524,288 /48, again if > the whole subTLA is used. So at the same time the 80% utilisation section > of the document needs to be worded correctly to allow ISPs to apply for > subsequent subTLA's. > That is: the 80% (or whatever utilisation) to refer to the number of /48s in a subTLA since ISPs will have no control over how and when our customers, home users, SOHOs, mobile users are going to utilise their /48 prefix! Regards George

1 0

IPv6 Policy Document Revision suggestion
by stuart.prevost＠bt.com 13 Jul '00

13 Jul '00

All, From reading all the emails it seems that the /48 approach as the *minimum* allocation is the way the IETF would like IPv6 deployment to proceed. However, as it has been demonstrated, the /35 allocations today would only allow for 8,192 /48 per subTLA, and this is assuming that the subTLA holder hasn't split up the NLA block so they can allocate to other providers, in which case this figure could be as small as 256 or lower!!!! I see this as the reason why ISPs consider /48 for a home customer as too large, and hence the sliding-window & /56 discussion at the last RIPE meeting. Now, if the /48 allocation is the way to proceed, I feel that all initial /35 allocations should be initially changed to /29 as the first step. This can be done easily as all allocations have the /29 reserved to ensure a contiguous block. However a /29 allows for 524,288 /48, again if the whole subTLA is used. So at the same time the 80% utilisation section of the document needs to be worded correctly to allow ISPs to apply for subsequent subTLA's. Also I would like to ask the following question: How do we move from the current allocations of /29 & /35 to RFC2374 (IPv6 Aggregatable Global Unicast Address Format) and at what stage will this happen? Otherwise I can see organisations holding multiple subTLA before moving to the address structure in RFC2374, and more renumbering pain. Regards, Stuart Stuart Prevost --------------------------------------------------- IP Specialist, Futures Testbed Tel: +44 1473 646891 Fax: +44 1473 643906 Mobile: +44 7801 977290 Email: stuart.prevost(a)bt.com Addr: B29/136 - Adastral Park, Martlesham Heath, Ipswich. Suffolk. IP5 3RE

3 2

Re: (ngtrans) Fw: [apnic-announce] IPv6 Policy Document Revision
by Joao Luis Silva Damas 11 Jul '00

11 Jul '00

Brian, At 10:29 -0500 7/7/00, Brian E Carpenter wrote: ...snip... > > A /64 for dialup >> is also too rigid because the way technology is going a /64 is not >>going to be >> enough subnets for what wiill be a dial up connection with a large >>lan behind it. > >Indeed. But that isn't an issue the RIRs need to think about. It is not the RIRs trying to force variable length prefixes. At the RIPE meeting in Budapest and the ARIN meeting in Calgary we reported what the outcome of conversations with IETF people was (the /48, /56, /64 options for allocation). This seemed to be a reasonable way of doing it for the IPv6/ngtrans IETF people and to the RIR people present in Adelaide. At both the ARIN and RIPE meetings, ISPs (the people who will use the address space, after all) were the ones that suggested variable length prefixes for allocation and the RIRs must go by the community consensus (BTW, at the RIPE meeting no consensus was reached, with both the variable length and the 3 fixed lengths having supporters). A second issue is to think about a way of getting the IETF IPv6 people and the 3 RIR communities to talk to each other at the same, otherwise we are entering a loop, with at least 4 separate discussions and each dependant on the other 3. Joao > Brian

6 6

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