- ipv6-wg - mailman.ripe.net

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

Fw: RFC 3041 on Extensions to IPv6 Address Autoconfiguration
by Thomas Trede 02 Feb '01

02 Feb '01

FYI. Regards, Thomas Trede ----- Original Message ----- From: "RFC Editor" <rfc-ed(a)ISI.EDU> To: <IETF-Announce: ;> Cc: <rfc-ed(a)ISI.EDU>; <ipng(a)sunroof.eng.sun.com> Sent: Friday, February 02, 2001 6:11 PM Subject: RFC 3041 on Extensions to IPv6 Address Autoconfiguration > > A new Request for Comments is now available in online RFC libraries. > > > RFC 3041 > > Title: Privacy Extensions for Stateless Address > Autoconfiguration in IPv6 > Author(s): T. Narten, R. Draves > Status: Standards Track > Date: January 2001 > Mailbox: narten(a)raleigh.ibm.com, richdr(a)microsoft.com > Pages: 17 > Characters: 44446 > Updates/Obsoletes/SeeAlso: None > > I-D Tag: draft-ietf-ipngwg-addrconf-privacy-04.txt > > URL: ftp://ftp.rfc-editor.org/in-notes/rfc3041.txt > > > Nodes use IPv6 stateless address autoconfiguration to generate > addresses without the necessity of a Dynamic Host Configuration > Protocol (DHCP) server. Addresses are formed by combining network > prefixes with an interface identifier. On interfaces that contain > embedded IEEE Identifiers, the interface identifier is typically > derived from it. On other interface types, the interface identifier > is generated through other means, for example, via random number > generation. This document describes an extension to IPv6 stateless > address autoconfiguration for interfaces whose interface identifier is > derived from an IEEE identifier. Use of the extension causes nodes to > generate global-scope addresses from interface identifiers that change > over time, even in cases where the interface contains an embedded IEEE > identifier. Changing the interface identifier (and the global-scope > addresses generated from it) over time makes it more difficult for > eavesdroppers and other information collectors to identify when > different addresses used in different transactions actually correspond > to the same node. > > This document is a product of the IPNG Working Group of the IETF. > > This is now a Proposed Standard Protocol. > > This document specifies an Internet standards track protocol for > the Internet community, and requests discussion and suggestions > for improvements. Please refer to the current edition of the > "Internet Official Protocol Standards" (STD 1) for the > standardization state and status of this protocol. Distribution > of this memo is unlimited. > > This announcement is sent to the IETF list and the RFC-DIST list. > Requests to be added to or deleted from the IETF distribution list > should be sent to IETF-REQUEST(a)IETF.ORG. Requests to be > added to or deleted from the RFC-DIST distribution list should > be sent to RFC-DIST-REQUEST(a)RFC-EDITOR.ORG. > > Details on obtaining RFCs via FTP or EMAIL may be obtained by sending > an EMAIL message to rfc-info(a)RFC-EDITOR.ORG with the message body > help: ways_to_get_rfcs. For example: > > To: rfc-info(a)RFC-EDITOR.ORG > Subject: getting rfcs > > help: ways_to_get_rfcs > > Requests for special distribution should be addressed to either the > author of the RFC in question, or to RFC-Manager(a)RFC-EDITOR.ORG. Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution.echo > Submissions for Requests for Comments should be sent to > RFC-EDITOR(a)RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC > Authors, for further information. > > > Joyce K. Reynolds and Sandy Ginoza > USC/Information Sciences Institute > > ... > > Below is the data which will enable a MIME compliant Mail Reader > implementation to automatically retrieve the ASCII version > of the RFCs. >

1 0

Classfull routing in the 21st Century
by Andrew Miehs 30 Jan '01

30 Jan '01

Dear colleagues, After looking at the material presented in RFC 2374 and the discussions in the working group at the 38th RIPE meeting I am left with a few questions. My understanding of IPv6 is that it is supposed to solve some of the problems that we have with IPv4. These include: - Running out of IPv4 address space - Difficulties of Route aggregation - Renumbering And a new problem addressed at the last RIPE meeting - Running out of AS Numbers (prediction mid 2005) (It will become obvious later why I mention this here) With the current proposal, I do not see that any of these problems will be adequately (or if at all) addressed. The most obvious problem is that the 13 bits of sTLA space that is being given to providers today is TOO small. One way of increasing this would be to implement CIDR in IPv6, and not to include EUI-64 interface addresses in the IP header. Is arp really that bad that we have to throw it away? There is no medium that I know of that can support 2^64 addresses in the one segment, and I see no advantage of shipping this information across the Internet. Mutlihoming and Renumbering are still very much up in the air. Aggregation (including the GSE (8+8) draft) all seem to base their design on the Internet Registries (RIPE, etc ) or 'Tier 1' providers having the most significant bits (leftmost) in an IP address. The problem I see with this approach is that - It is not usual for an ISP to 'Peer' with a routing registry, and therefore not really getting a great gain from route aggregation - How do you determine which Tier a provider belongs to, and should he change size, moving or down a Tier is almost impossible due to renumbering difficulties. A suggestion that I would like to throw into the ring would be to include the AS Number into the start of the IP Header, and maybe a bits after that, to help control entry/exit points into boarding networks (a type of tag). | 3| 21 | 8 | 24 | 8 | 64 bits | +--+-----+---+--------+--------+--------------------------------+ |FP| AS |TAG| NLA | SLA | Interface ID | | | NUM | | ID | ID | | +--+-----+---+--------+--------+--------------------------------+ or | 3| 21 | 8 | 32 | 64 bits | +--+-----+---+-----------------+--------------------------------+ |FP| AS |TAG| NLA | Customers address | | | NUM | | ID | Range (CIDR) | +--+-----+---+-----------------+--------------------------------+ depending whether one wanted to get rid of arp. This way the border routers would only require the path information on how to get from one AS to the other, without requiring detailed information on the prefixes. Dual homing would be solved by issuing those customers with their own AS number, as is the practice today. It is obvious however that the number of bits in an AS Number would have to be increased, but this is the case anyway. To ease renumbering it might make sense to issue the numbers out of a smaller range (96 bit for example). The customers edge routers would then add the current ISPs AS Number to the packet before forwading them out. This way, the only change required when chaing ISPs is on the boarder routers. The field lengths/ names above are just an example, and would have to be closely examined. I would be interested in hearing any opinions, Regards Andrew -- Andrew Miehs Cybernet AG email: amiehs(a)cybernet-ag.net phone: +49 89 993 15-0 fax : +49 89 993 15-199

2 1

Fw: I-D ACTION:draft-ietf-ipngwg-uni-based-mcast-01.txt
by Thomas Trede 29 Jan '01

29 Jan '01

FYI. Regards, Thomas Trede ----- Original Message ----- From: <Internet-Drafts(a)ietf.org> To: <IETF-Announce: ;> Cc: <ipng(a)sunroof.eng.sun.com> Sent: Monday, January 29, 2001 12:44 PM Subject: I-D ACTION:draft-ietf-ipngwg-uni-based-mcast-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 : 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 > > This specification defines an extension to the multicast addressing > architecture of the IP Version 6 protocol. The extension presented > in this document allows for unicast-prefix-based allocation of > multicast addresses. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-uni-based-mcast-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-uni-based-mcast-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-uni-based-mcast-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-addr-arch-v3-03.txt
by Thomas Trede 29 Jan '01

29 Jan '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, January 26, 2001 12:43 PM Subject: I-D ACTION:draft-ietf-ipngwg-addr-arch-v3-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 : IP Version 6 Addressing Architecture > Author(s) : B. Hinden, S. Deering > Filename : draft-ietf-ipngwg-addr-arch-v3-03.txt > Pages : 25 > Date : 25-Jan-01 > > This specification defines the addressing architecture of the IP > Version 6 protocol [IPV6]. The document includes the IPv6 addressing > model, text representations of IPv6 addresses, definition of IPv6 > unicast addresses, anycast addresses, and multicast addresses, and an > IPv6 node's required addresses. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-addr-arch-v3-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-addr-arch-v3-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-addr-arch-v3-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

[bmanning@vacation.karoshi.com: Closure?]
by David Kessens 26 Jan '01

26 Jan '01

FYI: ----- Forwarded message from bmanning(a)vacation.karoshi.com ----- X-Virus-Scanned: Fri, 26 Jan 2001 08:24:42 -0800 Nokia Silicon Valley Email Exploit Scanner From: bmanning(a)vacation.karoshi.com Subject: Closure? To: v6wg(a)arin.net Date: Fri, 26 Jan 2001 16:14:29 +0000 (UCT) X-Mailer: ELM [version 2.5 PL1] Precedence: bulk Good morning folks. This is to remind you that ARIN is still holding out on accepting the IAB/IESG recommendations for inital IPv6 delegation/allocation sizes. There was some lively discussion at the last mtg but the concerns generally came down to... "this makes me nervous and I don't understand it all to well." Yes, there are operational concerns but quite frankly, the number of people in the ARIN region that are able/willing to explore IPv6 seems to be either very small, not willing to share experiences, or are happy with the 6bone delegations. ARIN has pretty much removed the barriers to entry with the zero-cost delegation policy in place. Unless a viable counter proposal or modification to the existing IAB/IESG proposal that has been accepted by RIPE and APNIC, I'm going to recommend to the ARIN council that silence is consent and ARIN should adopt the IAB/IESG proposal for a /48 being the default delegation size, subject to review, based on operational experience. --bill ----- End forwarded message ----- David K. ---

1 0

Fw: W.G. Last Call on "A flexible method for an IPv6 addressing plan"
by Thomas Trede 17 Jan '01

17 Jan '01

FYI. Regards, Thomas Trede ----- Original Message ----- From: "Bob Hinden" <hinden(a)iprg.nokia.com> To: <ipng(a)sunroof.eng.sun.com> Sent: Tuesday, January 16, 2001 11:29 PM Subject: W.G. Last Call on "A flexible method for an IPv6 addressing plan" > This is a IPng working group last call for comments on advancing the > following document as an Informational RFC: > > Title : A flexible method for an IPv6 addressing plan > Author(s) : M. Blanchet > Filename : draft-ietf-ipngwg-ipaddressassign-01.txt > Pages : 13 > Date : 30-Nov-00 > > 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 January 30, 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: Request to Advance "Transmission of IPv6 Packets over IEEE 1394 Networks"
by Thomas Trede 17 Jan '01

17 Jan '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:13 PM Subject: Request to Advance "Transmission of IPv6 Packets over IEEE 1394 Networks" > 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 > Proposed Standard: > > Title : Transmission of IPv6 Packets over IEEE 1394 Networks > Author(s) : K. Fujisawa, A. Onoe > Filename : draft-ietf-ipngwg-1394-00.txt > Pages : 7 > Date : 14-Nov-00 > > A working group last call for this document was completed on December 12, > 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 > -------------------------------------------------------------------- >

1 0