- ipv6-wg - mailman.ripe.net

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

agenda for IPv6 working group RIPE38
by David Kessens 17 Jan '01

17 Jan '01

Hi, Below follows the final version of the agenda for the ipv6 wg. Please let me know if you have any other topics that you want to have discussed, we can still add them if time allows, but they won't show up at the official printed version of the meeting agenda. Thanks, David K. --- Agenda for the IPv6 Working Group Meeting RIPE38, Amsterdam Wednesday January 24, 2001, 14:00-17:30 1st part 14:00-15:30 A. Administrative stuff - appointment of scribe - agenda bashing (David Kessens) B. Status of the 6bone (David Kessens) C. DNS and IPv6 (Roy Arends, Nominum) 2nd part 16:00-17:30 D. European Union projects regarding IPv6 (Gordon Lennox, European Union) E. Revised ietf bcp based on ripe/apnic input (Randy Bush) F. Are /35's enough as initial allocations ?!? (Bernard Tuy) G. Developments/initiatives regarding IPv6 in the RIPE region and beyond (input from the audience) Z. AOB ---

1 0

final version of the IPv6 joint policy meeting minutes
by David Kessens 12 Jan '01

12 Jan '01

Hi, Please see below for the final version of the minutes of the joint session of the ipv6 wg and lir wg regarding ipv6 allocation policies at RIPE37. The only changes made to the draft are typographical. I would like to thank Vesna for taking the minutes. Thanks, David K. --- IPv6 joint policy meeting RIPE ipv6-wg & lir-wg Wednesday, 13 September 2000 RIPE 37 Chair: David Kessens Agenda i Statement of current policy draft ii IAB/IESG recommendations iii Panel discussion iv AOB =i= Statement of current policy draft -- Joao Damas, RIPE NCC One year ago 3 Regional Internet Registries produced document that outlines allocation of IPv6 address space. * size of end user assignments * multihoming considerations * what is the meaning of 80% usage in ipv6? We need the clear picture of these issues to move forward. [chair: Bob Hinden tries to present the opinion of the IAB/IESG as closely as possible, but he is not the official spokesman of those bodies] = ii = IAB/IESG Recommendations on IPv6 Address Allocation - Bob Hinden URL: http://www/ripe/meetings/archive/ripe-37/presentations/ripe-ipv6-hinden/ We do not have real issue on service provider allocations size. Our recommendation is: /48 fixed boundary for all subscribers. This is consistent with responsible stewardship of the IPv6 Address space. Reasoning: - allocation policies influence the deployment; policies should make deployment easy, not slow - renumbering is (still) not painless or automatic Exceptions: - very large subscribers should get multiple /48:s, or /47 - transient nodes (roaming, dial-up) (/64) - explicitly no interest in subnetting Justifications for fixed boundary: - easy to change ISP:s (does not require restructuring of subnets) - straightforward renumbering - compatible with current multihoming proposals - allows easy growth of subscribers - reduces burden of ISP:s and RIR:s to judge customers' needs - no need for details of customers' networks - no need to judge rates of consumption - no scarcity of subscriber's space: no need for NAT - allows single reverse DNS zone (for all prefixes) Conservation: - does this waste IPv6 address space? No. - this distribution had better H ratio (RFC1715) then many others today - still, only one of the Format Prefixes (001) is going to be used; it leaves 85% of total IPv6 space for future usage and possible stricter policy Multihoming: IETF is still looking for input on this issue. = iii= Panel discussion: 1. Stephen Burley (UUNET) 2. Steve Deering (ipng) 3. Joao Damas (RIPE NCC) 4. Bob Hinden (ipng) 5. Randy Bush (ngtrans) 6. Juergen Rauschenbach (ipv6 forum) Q: What is criteria for ISP allocation? How much IPv6 address space does an ISP get? A: (Randy) This proposal is not changing other parts of policy. All will still get a /35. Normal slow start. Q: (Dave Pratt) Could you clarify what is meant by the 80% rule? A: (Bob) 80% of number of customers (ISP needs to allocate 80%, not the subscribers) Q: (Dave) I guess what I really mean is to do with ISP/LIR addressing hierarchy. It's difficult to build in hierarchy if aiming for 80% utilisation before more addresses will become available. Steve: H-ratio may be more appropriate rather than a percentage. A: I would suggest 20%. For example with 20% you can reserve addresses for 8 regions, and not worry if 6 of the 8 sites have small take up rates. A: (Steve) "you can start without hierarchy, and then add it later when the need arises". A: We could add hierarchy later, but maybe not really (same problems later as at start). We should be designing our networks correctly from the beginning. A: Discussion of possibility of H ratio's also being applied also to the LIR/ISP address range. Randy points out that with allocating /48s in a /35, the H ratio might be different, but the principle still holds, and there is a believe that there are enough addresses in IPv6 (also mentions in passing that the same believe existed in the early days of IPv4) Q: (Wilfried Woeber) Thank you for the clear document and clarification. Remaining issue: number of bits available for infrastructure. There should be a recommendation to start with the least significant bits. A: (Steve) We need an analysis regarding building an efficient hierarchy in the top 8 bits. If the community agrees on the /48 boundary, we may have to review the size of the initial allocation (/35 subTLA size). Joao explains why the /35 has been chosen. One gets 8192 NLA ranges, which can each by itself be structured and managed. This means it is actually more than if one gets a /19 in IPv4. Randy wonders why WW thinks one has a different problem in v6 than today in v4. The ISP he works for aggregates per pop, very strict and successful about it, but announce a /19 or shorter per pop. /35 feels as comfortable. Tries to understand if people don't feel comfortable with that and why. A: 13 bits (/35) is fine, it allows for aggregation per pop, the problem is the 80% usage rate. Randy: isn't the problem the percent, not matter how much it is? A: Problem is if the pops grow at different speed. A: Gert Doering, space net, Germany: We started with /19. By now, we have /16 and few /19:s, and they are not aggregated. We have resellers, and they have theirs. It fragments awfully. I am in favour of /56; or, I do not mind /48 if we can get bigger prefix (more bits) in the front. I do not need more space, but more possibility to build the hierarchy and aggregate. Joao: You have /29 contiguous block reserved to grow into. Gert: I don't see the need for slow start. There are so many /29s that the routing tables would explode before the /29s were exhausted. Bob suggests that might be solvable by rethinking the 80% usage rate (so that ISPs are not penalised for taking a long-term view from the start). Randy: He is in Frankfurt and Bon, and peers with Jurgen at both places, and announces same /35 at both places and Jurgen does not know to which one to send traffic. Chair: Want to refocus back on the recommendations of the draft. People seem to be OK with the /48. Let's move on. Need to come up with something to put in the multihoming section. For now, IPv4 method of multihoming should be used, as a short term recommendation. There is also the option to use multiple prefixes. The philosophy should be that addresses are cheap, so if someone wants to experiment with the multi address multihoming, let them and give them the addresses. Q: (Dave Pratt) Present PI space is authorised by RIPE and does NOT come from provider assigned space. I think this is a good rule (until better multihoming techniques are developed) that should be continued for IPv6. Alain Durand: Wants to emphasise that it's early in deployment and we need lots of feedback regarding whether multihoming techniques etc work. Be generous with /48s. Randy: From the proposal "if they need more address space, they get multiple /48:s". I would suggest /47. Steve: Looking to create a team to investigate how to measure usage. Maybe find a H ratio measure to apply instead of the 80% rule. Joao: the conservation is not the only issue here. WW: We want to keep the routing table small. (...) Randy: Small number of providers having TLA does not look good from the market point of view and it would create the small club who owns the Internet. A: The requirement is not only to aggregate well (shrinks the table), but also to find neutral mechanism of allocation; how to get into that club. Chair: Do you have enough info on /48 proposal? (yes) Chair: OK recommendation of this group is that /48 assignments should go ahead. This will be taken to ARIN and APNIC.

1 0