- ipv6-wg - mailman.ripe.net

IPv6 joint policy meeting minutes
by David Kessens 23 Dec '00

23 Dec '00

Hi, Please see below for the minutes of the joint session of the ipv6 wg and lir wg regarding ipv6 allocation policies at RIPE37. The minutes will be declared final by January 5 if I don't receive any comments other than typographical errors and other minor corrections. 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: (Wilfred 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 v 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 a so many /29s 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 recommendations of this group are that /48 assignments are to go ahead. This will be taken to ARIN and APNIC.

1 0

RE: Good news: IPv6 & GPRS
by Koos Varkevisser 08 Dec '00

08 Dec '00

hope Siemens will follow..... ;-) ------------------------------------ Koos Varkevisser Energis (Netherlands) N.V. Data Center Services / datacom engineer K.P. van der Mandelelaan 130-144 3062 MB Rotterdam the Netherlands Tel. +31.10.8803922 Fax. +31.10.8803901 Mob. +31.6.54353064 XOIP. +31.20.8680628 -----Original Message----- From: Hans Petter Holen [mailto:hph@online.no] Sent: Tuesday, December 05, 2000 3:59 PM To: ipv6-wg(a)ripe.net Subject: Good news: IPv6 & GPRS Ath the last couple of RIPE meetings IPv6 seemed not to be a realistic option for GPRS. Now at least one vendor seems to do something about that: http://press.nokia.com/PR/200011/798516_5.html -hph

1 0

Good news: IPv6 & GPRS
by Hans Petter Holen 05 Dec '00

05 Dec '00

Ath the last couple of RIPE meetings IPv6 seemed not to be a realistic option for GPRS. Now at least one vendor seems to do something about that: http://press.nokia.com/PR/200011/798516_5.html -hph

1 0

Fw: I-D ACTION:draft-ietf-ipngwg-addrconf-privacy-04.txt
by Thomas Trede 01 Dec '00

01 Dec '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, December 01, 2000 12:29 PM Subject: I-D ACTION:draft-ietf-ipngwg-addrconf-privacy-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 : Privacy Extensions for Stateless Address > Autoconfiguration in IPv6 > Author(s) : T. Narten, R. Draves > Filename : draft-ietf-ipngwg-addrconf-privacy-04.txt > Pages : 17 > Date : 30-Nov-00 > > Nodes use IPv6 stateless address autoconfiguration to generate > addresses without the necessity of a 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. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-addrconf-privacy-04.tx t > > 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-addrconf-privacy-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-ipngwg-addrconf-privacy-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

Fw: I-D ACTION:draft-ietf-ipngwg-ipaddressassign-01.txt
by Thomas Trede 01 Dec '00

01 Dec '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, December 01, 2000 12:29 PM Subject: I-D ACTION:draft-ietf-ipngwg-ipaddressassign-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 : A method for flexible IPv6 address assignments > Author(s) : M. Blanchet > Filename : draft-ietf-ipngwg-ipaddressassign-01.txt > Pages : 13 > Date : 30-Nov-00 > > This document presents a method that helps organisations that makes > addressing plan for IP addresses. The flexibility enables the > organisation to postpone the final decision on the number of bits to > partition in the address space they have. It does it by keeping the > bits around the borders of the partition to be free as long as > possible. This scheme is applicable to any bits addressing scheme > using bits with partitions in the space, but its first intended use > is for IPv6. It is a generalization of RFC1219 and can be used for > IPv6 assignments based on RFC2373 and RFC2374. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-ipaddressassign-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-ipaddressassign-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-ipaddressassign-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-default-addr-select-02.txt
by Thomas Trede 30 Nov '00

30 Nov '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, November 30, 2000 11:51 AM Subject: I-D ACTION:draft-ietf-ipngwg-default-addr-select-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 : Default Address Selection for IPv6 > Author(s) : R. Draves > Filename : draft-ietf-ipngwg-default-addr-select-02.txt > Pages : 19 > Date : 29-Nov-00 > > This document describes two algorithms, for source address selection > and for destination address selection. The algorithms specify > default behavior for all IPv6 implementations. They do not override > choices made by applications or upper-layer protocols, nor do they > preclude the development of more advanced mechanisms for address > selection. The two algorithms share a common framework, including an > optional mechanism for allowing administrators to provide policy > that can override the default behavior. In dual stack > implementations, the framework allows the destination address > selection algorithm to consider both IPv4 and IPv6 addresses - > depending on the available source addresses, the algorithm might > prefer IPv6 addresses over IPv4 addresses, or vice-versa. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-default-addr-select-02 .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-default-addr-select-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-default-addr-select-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: DNSEXT WG Last Call: Message Size
by Thomas Trede 30 Nov '00

30 Nov '00

FYI. Regards, Thomas Trede ----- Original Message ----- From: "Olafur Gudmundsson" <ogud(a)tislabs.com> To: "DNSEXT WG Mailing list" <namedroppers(a)ops.ietf.org> Cc: <ipng(a)sunroof.eng.sun.com> Sent: Wednesday, November 29, 2000 8:17 PM Subject: DNSEXT WG Last Call: Message Size > This is a DNSEXT WG last call on this document, please send your comments > to mailto:namedroppers@ops.ietf.org > > This document updates RFC2535 and RFC2874 (A6) to demand larger > UDP message size than 512 bytes. This document mandates that any > entity supporting either DNSSEC or A6 records must support EDNS0 on queries > and responses. > The motivation(s) for this is the increase in size of DNS answers caused > by DNSSEC, IPng, TSIG and large the desire for large answer sets. > The document assumes that modern operating systems can do UDP reassembly, > thus this the single UDP message requirement can be relaxed and this is > less costly than falling back on TCP for all large answers. > > This WG last call ends December 17'th 2000. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-message-size-01.txt > > This draft is on standards track, if you disagree with that please state why > in your response. > > Olafur > > > > -------------------------------------------------------------------- > 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-dns-discovery-00.txt
by Thomas Trede 29 Nov '00

29 Nov '00

FYI. Regards, Thomas Trede ----- Original Message ----- From: <Internet-Drafts(a)ietf.org> To: <IETF-Announce: ;> Cc: <ipng(a)sunroof.eng.sun.com> Sent: Wednesday, November 29, 2000 12:27 PM Subject: I-D ACTION:draft-ietf-ipngwg-dns-discovery-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 : Analysis of DNS Server Discovery Mechanisms for IPv6 > Author(s) : D. Thaler > Filename : draft-ietf-ipngwg-dns-discovery-00.txt > Pages : 43 > Date : 28-Nov-00 > > There are any number of ways that IPv6 hosts can discover > information required to enable name resolution, in the absence of > a DHCP server. This document discusses the issues and provides a > taxonomy of possible solutions, and evaluates them against various > design criteria. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-dns-discovery-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-dns-discovery-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-dns-discovery-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 "Transmission of IPv6 Packets over IEEE 1394 Networks"
by Thomas Trede 29 Nov '00

29 Nov '00

FYI. Regards, Thomas Trede ----- Original Message ----- From: "Bob Hinden" <hinden(a)iprg.nokia.com> To: <ipng(a)sunroof.eng.sun.com> Sent: Wednesday, November 29, 2000 1:02 AM Subject: W.G. Last Call on "Transmission of IPv6 Packets over IEEE 1394 Networks" > This is a IPng working group last call for comments on advancing the > following document as a 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 > > 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 December 12, 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: I-D ACTION:draft-haberman-ipngwg-auto-prefix-00.txt]
by Thomas Trede 27 Nov '00

27 Nov '00

FYI. Regards, Thomas Trede ----- Original Message ----- From: "Brian Haberman" <haberman(a)nortelnetworks.com> To: "IPng Mailing List" <ipng(a)sunroof.eng.sun.com> Sent: Monday, November 27, 2000 3:19 PM Subject: [Fwd: I-D ACTION:draft-haberman-ipngwg-auto-prefix-00.txt] > All, > The following is an individual submission discussing automated > prefix delegation. The basic idea is that routers can request a prefix > to use within a network. Right now, we restrict its use to leaf > networks, but are working on expanding it. Comments welcome. > > Regards, > Brian > > Internet-Drafts(a)ietf.org wrote: > > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > > Title : Automatic Prefix Delegation Protocol for Internet > > Protocol Version 6 (IPv6) > > Author(s) : B. Haberman, J. Martin > > Filename : draft-haberman-ipngwg-auto-prefix-00.txt > > Pages : 11 > > Date : 22-Nov-00 > > > > The expansion of the IP address space provided by IPv6 makes it both > > possible and reasonable to allocate entire subnets to environments > > that had been previously limited to a few individual IP addresses. > > Other protocols such as Neighbor Discovery and Stateless Address > > Autoconfiguration allow hosts within those subnets to be > > automatically configured. The router between this subnet and the > > upstream world requires just one more piece to make this process > > automatic, a network prefix. > > This document describes a mechanism for the automated delegation of > > an IPv6 network prefix. It allows routers to request a specific size > > prefix and inform the upstream router of the routing protocols of > > which it is capable. Upon authorizing the request the delegating > > router then returns a prefix, the desired routing protocol, and a > > lifetime for the use of the prefix. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-haberman-ipngwg-auto-prefix-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-haberman-ipngwg-auto-prefix-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-haberman-ipngwg-auto-prefix-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. > > > ------------------------------------------------------------------------ > -------------------------------------------------------------------- > 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