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

Fw: W.G. Last Call on "Unicast-Prefix-based IPv6 Multicast Addresses"
by Thomas Trede 28 Feb '01

28 Feb '01

FYI. Regards, Thomas Trede ----- Original Message ----- From: "Bob Hinden" <hinden(a)iprg.nokia.com> To: <ipng(a)sunroof.eng.sun.com> Sent: Tuesday, February 27, 2001 4:35 PM Subject: W.G. Last Call on "Unicast-Prefix-based IPv6 Multicast Addresses" > This is a IPng working group last call for comments on advancing the > following document as a Proposed Standard: > > Title : Unicast-Prefix-based IPv6 Multicast Addresses > Author(s) : B. Haberman, D. Thaler > Filename : draft-ietf-ipngwg-uni-based-mcast-01.txt > Pages : 5 > Date : 26-Jan-01 > > Please send substantive comments to the ipng mailing list, and minor > editorial comments to the authors. This last call period will end two > week from today on March 13, 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

Fw: I-D ACTION:draft-vida-mld-v2-00.txt
by Thomas Trede 27 Feb '01

27 Feb '01

FYI. Regards, Thomas Trede ----- Original Message ----- From: <Internet-Drafts(a)ietf.org> To: <IETF-Announce: ;> Cc: <ipng(a)sunroof.eng.sun.com> Sent: Tuesday, February 27, 2001 12:52 PM Subject: I-D ACTION:draft-vida-mld-v2-00.txt > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Multicast Listener Discovery Version 2 (MLDv2) for > IPv6 > Author(s) : R. Vida et al. > Filename : draft-vida-mld-v2-00.txt > Pages : 48 > Date : 26-Feb-01 > > This document specifies Version 2 of the Multicast Listener Discovery > protocol, MLDv2. MLD is the protocol used by an IPv6 router to > discover the presence of multicast listeners (that is, nodes wishing > to receive multicast packets) on its directly attached links, and to > discover specifically which multicast addresses are of interest to > those neighboring nodes. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-vida-mld-v2-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-vida-mld-v2-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-vida-mld-v2-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 "Basic Socket Interface Extensions for IPv6"
by Thomas Trede 22 Feb '01

22 Feb '01

FYI. Regards, Thomas Trede ----- Original Message ----- From: "Bob Hinden" <hinden(a)iprg.nokia.com> To: <ipng(a)sunroof.eng.sun.com> Sent: Thursday, February 22, 2001 12:39 AM Subject: W.G. Last Call on "Basic Socket Interface Extensions for IPv6" > This is a IPng working group last call for comments on advancing the > following document as an Informational RFC: > > Title : Basic Socket Interface Extensions for IPv6 > Author(s) : R. Gilligan, S. Thomson, J. Bound, W. Stevens > Filename : draft-ietf-ipngwg-rfc2553bis-03.txt > Pages : 31 > Date : 12-Feb-01 > > Please send substantive comments to the ipng mailing list, and minor > editorial comments to the authors. This last call period will end two > week from today on March 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

Fw: Last Call: Transmission of IPv6 Packets over IEEE 1394 Networks to Proposed Standard
by Thomas Trede 20 Feb '01

20 Feb '01

FYI. Regards, Thomas Trede ----- Original Message ----- From: "The IESG" <iesg-secretary(a)ietf.org> To: <IETF-Announce: ;> Cc: <ipng(a)sunroof.eng.sun.com> Sent: Monday, February 19, 2001 8:50 PM Subject: Last Call: Transmission of IPv6 Packets over IEEE 1394 Networks to Proposed Standard > > The IESG has received a request from the IPNG Working Group to consider > Transmission of IPv6 Packets over IEEE 1394 Networks > <draft-ietf-ipngwg-1394-01.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 March 5, 2001. > > Files can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-1394-01.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

Fw: I-D ACTION:draft-ietf-ipngwg-1394-01.txt
by Thomas Trede 15 Feb '01

15 Feb '01

FYI. Regards, Thomas Trede ----- Original Message ----- From: <Internet-Drafts(a)ietf.org> To: <IETF-Announce: ;> Cc: <ipng(a)sunroof.eng.sun.com> Sent: Thursday, February 15, 2001 12:46 PM Subject: I-D ACTION:draft-ietf-ipngwg-1394-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 : Transmission of IPv6 Packets over IEEE 1394 Networks > Author(s) : K. Fujisawa, A. Onoe > Filename : draft-ietf-ipngwg-1394-01.txt > Pages : 8 > Date : 14-Feb-01 > > IEEE Std 1394-1995 is a standard for a High Performance Serial Bus. > This document describes the frame format for transmission of IPv6 > [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 [DISC] when the messages are > transmitted on an IEEE1394 network. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-1394-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-1394-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-1394-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. >

1 0

Fw: I-D ACTION:draft-ietf-ipngwg-rfc2553bis-03.txt
by Thomas Trede 13 Feb '01

13 Feb '01

FYI. Regards, Thomas Trede ----- Original Message ----- From: <Internet-Drafts(a)ietf.org> To: <IETF-Announce: ;> Cc: <ipng(a)sunroof.eng.sun.com> Sent: Tuesday, February 13, 2001 12:59 PM Subject: I-D ACTION:draft-ietf-ipngwg-rfc2553bis-03.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 : Basic Socket Interface Extensions for IPv6 > Author(s) : R. Gilligan, S. Thomson, J. Bound, W. Stevens > Filename : draft-ietf-ipngwg-rfc2553bis-03.txt > Pages : 31 > Date : 12-Feb-01 > > The de facto standard application program interface (API) for TCP/IP > applications is the 'sockets' interface. Although this API was > developed for Unix in the early 1980s it has also been implemented on a > wide variety of non-Unix systems. TCP/IP applications written using the > sockets API have in the past enjoyed a high degree of portability and we > would like the same portability with IPv6 applications. But changes are > required to the sockets API to support IPv6 and this memo describes > these changes. These include a new socket address structure to carry > IPv6 addresses, new address conversion functions, and some new socket > options. These extensions are designed to provide access to the basic > IPv6 features required by TCP and UDP applications, including > multicasting, while introducing a minimum of change into the system and > providing complete compatibility for existing IPv4 applications. > Additional extensions for advanced IPv6 features (raw sockets and access > to the IPv6 extension headers) are defined in another document [4]. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-rfc2553bis-03.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-rfc2553bis-03.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-rfc2553bis-03.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

6.0.1.0.0.2.ip6.int. vanished?
by Hauke Johannknecht 12 Feb '01

12 Feb '01

-----BEGIN PGP SIGNED MESSAGE----- Hi. I might haved missed some things in the last weeks but it looks like the delegation of 6.0.1.0.0.2.ip6.int. to RIPE has vanished from DNS? Is it supposed to be this way? Have we moved to "whatever v6-rdns is supposed to be this year"? Gruss, Hauke - -- Hauke Johannknecht Berlin / Germany HJ422-RIPE Use PGP ! -> lynx -dump http://www.ash.de/ash.asc | pgp -kaf -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQEVAwUBOobGXHO2fBh4VhzZAQHYgwgAmM/Q+PA2maIqJRDrQEJgscBCHtJjyna5 ocdeG0xBKo5Vwb/EwHic1rR6BzDI35IQrPsMOBXiRLVSEOCGjSIeqplqDy6dqORB EoN9pJQHsgsb4y6t2VZAqQfBvesUzUr49omihm3bn2JYRu+gQE3cXTd7jRypnIo9 +pWIwL4hecJUbH9ZuFRWkUkcGcmVQn/hjFd6K4XlHj2DbgKQXQJRQuTMJAqCUVcy ODRQHYqlv+ApXhiQcFPv9qXW3Csut6NqcrzhfR93JQPjvOfDQHI0OreYR6ZU3wFJ O/Gyv6/GHxLWDuI1L0V8Ypthbo6QbuW9MjKP/GNthjUhABR55EyGGA== =+Nn0 -----END PGP SIGNATURE-----

3 2

Fw: I-D ACTION:draft-ietf-ipngwg-site-prefixes-05.txt
by Thomas Trede 12 Feb '01

12 Feb '01

FYI. Regards, Thomas Trede ----- Original Message ----- From: <Internet-Drafts(a)ietf.org> To: <IETF-Announce: ;> Cc: <ipng(a)sunroof.eng.sun.com> Sent: Friday, February 09, 2001 1:24 PM Subject: I-D ACTION:draft-ietf-ipngwg-site-prefixes-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 : Site prefixes in Neighbor Discovery > Author(s) : E. Nordmark > Filename : draft-ietf-ipngwg-site-prefixes-05.txt > Pages : 22 > Date : 08-Feb-01 > > This document specifies extensions to IPv6 Neighbor Discovery to > carry site prefixes. The site prefixes are used to reduce the effect > of site renumbering by ensuring that the communication inside a site > uses site-local addresses. > This protocol requires that all IPv6 implementations, even those that > do not implement this protocol, ignore all site-local addresses that > they retrieve from the DNS when the AAAA or A6 RRset contain both > global and site-local addresses. If the RRset contains only site- > local addresses those addresses can be used. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-site-prefixes-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-site-prefixes-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-site-prefixes-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. >

1 0

Proposals on IPv6 Allocation policy
by Dave Pratt 08 Feb '01

08 Feb '01

Hiya all, Here are some thoughts on IPv6 allocation policy. Hopefully the resulting discussion will be active and constructive, resulting in appropriate feedback, policy, IETF-drafts, RFCs, etc. If the text below gets corrupted then you should be able to view it at: http://www.djp.net/ipv6/proposal.html This concerns the LIR and IPv6 WG at RIPE and I4ve sent to both lists accordingly. I suggest all replies/discussion be carried out primarily on the IPv6 list. Cheers Dave Viag Interkom GmbH ----------------------------- Proposals on IPv6 Allocation policy Hierarchy versus Address Conservation The RIR allocation policies for IPv6 appear to be based on the assumption that IPv6 addresses are a scarce resource that are about to run out. This assumption is totally untrue. Instead RIR allocation policies need to be focussed 90% on aggregation and hierarchy, and optimising the global routing table. One of the worst mistakes an RIR can make is to allocate too few addresses to an LIR, resulting in later subsequent allocations and pollution of the global routing table. Classbased versus Convenience: What is appropriate for an "alpine village" ISP is not appropriate for a large global ISP. LIR should not therefore all receive the same "standard prefix" but receive sensible allocations based on reasonable long term expectations on use. We should aim so that only 10% or so of LIR need to come back to ask for a second allocation within 5 years. Dividing on strange bit boundaries (eg. /35) in combination with the format of writing IPv6 addresses makes notation and calculation very hard for most people and will result in many mistakes over time. In such a large address space the benefits of always making allocations on a 4 bit boundary are greater than the resulting inflexibility. This is seen in the original TLA /16 and NLA /24 proposals. Allocations should be at /16, /24 or /32 - possibly /20 /28. Sub allocations by LIR to their customer ISPs should similarly be /32 /40, or possibly /36 /44. Present Allocation sizes: Bit usage density should be allocated evenly over the addressing hierarchy. I could use rfc1715's h-ratio here but refuse to use a measurement unit where everything is squashed between 0 and 0.301. At present a "site" has 80 bits (fixed at /48). Of these the average usage is likely to be 10 to 100 nodes (ranging from 10k for a medium corporation to 1-5 for the far more predominant home user). The usage density is therefore approx: 2^80/100 or well over 1 in 10^20 !!! can be certain there will not be more than around 100,000 top level routes. Accordingly the usage density is 2^35/100,000 or approx 1 in 350,000. An LIR with a present /35 and only a single customer (/48) has already reached a density of 1 in 8192 !!! Does anyone know why the service provider is treated differently ? The need for hierarchy within an LIR: In practise an LIR must introduce hierarchy to prevent excessive routes. Global LIRs must do this at multiple levels. Typically a Global LIR might have about 10 regions and about 10 areas per region - although hopefully these would not all be fixed in size. This hierarchy must be set at the outset, although a fraction (say up to 2/3) could be reserved to provide additional resources to areas/regions that grow faster than originally expected. In each of these approx. 100 areas, the larger LIRs (national or global) will have predominantly X customers who are small and/or medium size ISP's. The smallest of these would typically expect to have enough addresses to serve 256 customers - /40. Accordingly a minimum allocation for such an LIR forseeable at the outset is at least a /24. Minimal initial allocation based on registered IPv4 usage We must not allocate too few addresses to an LIR since this will cause problems for us all, and especially him and his customers now and in the future. Since addresses are not in short supply, and one of the worst mistakes an RIR can make is to allocate too few addresses, a minimum first allocation could be based on the customers current REGISTERED IPv4 usage. In fitting with the above sections a possible simple yet flexible approach would be to adopt the following table: Small - /40 Medium - /32 Large/National - /24 International - /16 These categories also fit extremely well with the present RIPE membership categories which could help reduce administrative checking of claims to be Large/National, etc. Until Multihoming issues are sorted (see also below) we must adopt a similar approach to corporate LIRs. With the category used calculated as if they were not a corporate LIR. A side effect of this rule is that it will encourage owners of historical non-registered allocations to register them with one of the RIRs (if they want an appropriate IPv6 allocation). These are minimum initial allocations. Larger initial allocations can be requested if appropriately justified. For example a new 3G UMTS consortium operating in a major european country but which has no LIR background would typically qualify for the same prefix as a large/national LIR Usage requirements for additional allocations: IPv4 addresses are in short supply, appropriately there is therefore a rule stating that 80% of addresses at each level must be "used" before additional addresses are "provided". In IPv6 this rule is not only invalid, it just does not make sense. Even more crazily, RFC2450 states 90% !!! In order to prevent stupid wastage and bad network design, this rule should not be relaxed below about 10% (I am reminded of a network I came across using RFC1916 addresses where a /16 was assigned to each of 100 sites - which varied from 5 to 10,000 nodes). In contrast 80% or 90% is unnecessary and unreachable in IPv6 where addresses are not a scarce resource. Multihoming and allocations to non-service providers: At the time of writing no fully satisfactory multihoming technique is available. We must therefore provide current owners of globably routed IPv4 address space with a TLA with an appropriate mask. Failure to do this will actively discourage organisations considering a move to IPv6. We must be pragmatic, and at the same time encourage IPv6 use.

1 0

Fw: Request to Advance "IPv6 multihoming support at site exit routers"
by Thomas Trede 06 Feb '01

06 Feb '01

FYI. Regards, Thomas Trede ----- Original Message ----- From: "Bob Hinden" <hinden(a)iprg.nokia.com> To: <Erik.Nordmark(a)eng.sun.com>; <narten(a)raleigh.ibm.com> Cc: <scoya(a)ietf.org>; <ipng(a)sunroof.eng.sun.com> Sent: Tuesday, January 16, 2001 11:19 PM Subject: Request to Advance "IPv6 multihoming support at site exit routers" > Erik, Thomas, > > The chairs of the IP Next Generation working group, on behalf of the > working group, request that the following document be published as an > Informational RFC: > > 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 > > A working group last call for this document was completed on August 17, 2000. > > Bob Hinden / Steve Deering > IPng Working Group Co-Chairs > > -------------------------------------------------------------------- > 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 > -------------------------------------------------------------------- >

4 4