Re: Enforcing unreachability of site local addresses
Kurtis: Thanks for your thoughtful response. I'll reply to your queries inline. AEB On Fri, 14 Feb 2003, Kurt Erik Lindqvist wrote: > > Most end-user network managers I deal with require these > > characteristics > > of their public network address allocations: > > > > 1) uniqueness (sometimes expressed as "autonomy") > > Wait. This is interesting. From what people here was saying before - I > drew the conclusion that end-users wanted non-uniqueness aka > site-locals to hide their topology. You are saying something else? > Please note the keyword "public" in the statement above. This applies (in the cases of most of my clients) to address spaces which are advertised to the public networks (AKA The Internet). Now, in answer to your implied question about addressing for private (internal) networks: Given the choice, most (in fact, nearly all) of my clients would prefer to run their internal networks on registered, unique, globally routable address space; this greatly simplifies the task of providing access to resources on the public network, and of providing access from the public networks to resouces which the external customers of the business desire to use, usually with the result of generating revenue for the business. Furthermore, the use of unique, globally routable address space vastly simplifies the task of establishing connections to networks operated by business partners (eg, vendors and larger customers), whether via the public network or over private links. However, my clients are wholly unwilling to run even the slightest risk of a forced renumbering on their internal networks. Full stop. No exceptions, and no equivocations. If unique and stable globally routable space is not available for use in their internal networks, my clients see non-unique, globally non-routable space, coupled with NAT, as a feasible (but not desirable) alternative: at least they have a reasonable expectation that such addressing will be stable, and that a forced renumbering is unlikely. For IPv6, the site local space meets the requirement for internal networks of address stability. That the SL (or, for IPv4, PNN) space is globally non-routable mitigates somewhat the inconvenience of maintaining NAT: if you use application-level gateways in addition to NAT, the ACLs can be less complex (although not less carefully crafted) than otherwise. With such an implementation, it becomes relatively straightforward to obscure the details of internal network structure (at least from the standpoint of the public networks) since neither the prefix nor the internal structure is advertised beyond the local environment. And yes, these clients do realise that the above steps are not alone sufficient to forestall intrusion or other malicious acts. > > 2) portability > > I can see that. > > > 3) stability > > Do you mean as a derivate of portability or for some other reason? > No. The stability requirement is quite independent of portability. My clients desire to avoid renumbering at any cost short of summary hanging; where it is not posiible to avoid renumbering, they wish to renumber as few systems as possible, and they would much rather change a static translation mapping than reconfigure a host. Where these clients are forced into renumbering (say, when they have to change ISPs as a result of poor service), they are vastly dissatisfied and profoundly resentful. For public network address spaces, portability is an aid in achieving stability, but hosts will have stable numbering even if the public network addressing is neither portable or stable. I think that the prevailing opinion in this WG has been that the situation described above (at least, the worst-case configuration) is not desirable. > > In many cases, requirement two is driven by a desire to implement > > multiple connections to the public networks via more than one service > > provider (multihoming). > > > So by portability you mean the ability to have a prefix announcement > accepted by multiple providers. > No, although that is one element. The specific meaning attached to "portable" by most of my clients is this: "when I discontinue service with any ISP (actually, Internet Access Provider, as most of my clients maintain the services - that is, hosts and applications, including DNS and SMTP - inhouse), the addressing of my hosts as seen from the public networks remains with me. Furthermore, I can advertise the (usually native) addresses of my hosts via any combination of access providers willing to carry the traffic and provide transit routing." > > While PI is not an absolute requirement, the present state of our > > > > The above properties of a prefix is not the same as PI, as well as PI > properties are not the same as above. For both IPv4 and IPv6. > > > technology and standards (for v6 as well as v4) force us to PI as the > > only > > implemented mechanism which satisfies the functional requirements > > enumerated above. If we can develop and writ
RE: Enforcing unreachability of site local addresses
> Tony Hain wrote: > We are at an impass. Indeed. > this puts the ADs in a bind, because they would have a hard > time justifing that the IPv6 wg should be tasked with defining > an operational plan that an Operations Area wg is already > tasked to do. Yep. Some will remember that in an attempt to shake things up, a year or two ago I tried to bypass multi6 and sent my text to ngtrans. The result was the addition of text in the ngtrans charter that specifically labeled multihoming solutions as non-goals that would not be looked at by the WG. We're deadlocked. > It is exactly that business model where PI approaches like > Michele's or mine work well. To set the record straight, Tony's drafts have been one of the major sources inspiring GAPI in the early stages. One of the interim releases of MHAP actually used Tony's scheme before GAPI was written. > I have a document that describes the situation and need for PI: > http://www.tndh.net/~tony/ietf/ipv6piaddressusage-04.txt I never bothered writing something like this as Tony's text is also valid for GAPI for the most part. Read it. Michel. 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 [EMAIL PROTECTED]
Re: Enforcing unreachability of site local addresses
Most end-user network managers I deal with require these characteristics of their public network address allocations: 1) uniqueness (sometimes expressed as "autonomy") Wait. This is interesting. From what people here was saying before - I drew the conclusion that end-users wanted non-uniqueness aka site-locals to hide their topology. You are saying something else? 2) portability I can see that. 3) stability Do you mean as a derivate of portability or for some other reason? In many cases, requirement two is driven by a desire to implement multiple connections to the public networks via more than one service provider (multihoming). So by portability you mean the ability to have a prefix announcement accepted by multiple providers. While PI is not an absolute requirement, the present state of our The above properties of a prefix is not the same as PI, as well as PI properties are not the same as above. For both IPv4 and IPv6. technology and standards (for v6 as well as v4) force us to PI as the only implemented mechanism which satisfies the functional requirements enumerated above. If we can develop and write into the standards some (Someone could say NAT and SL but I am glad you didn't) Agreed. For those end-user-network managers who are aware of the details of the NREN allocations, this situation provokes pure, incandescent fury: the academic entities are seen as having been granted special (and grossly preferential) treatment, while the commercial (as distinguished from service-provider) networks are subject to callous indifference and excluded thereby from direct access to stable network address allocations. We can't even claim "separate but equal" for this state of affairs, and the universal principle of Brown V. Board of Education still holds, even for networks. [For those not familiar with recent US history, send me mail directly for a brief explanation of the above reference. AEB] I am not familiar with the above, but I generally tend to agree that NREN and other networks are far different. For good and bad. Most of the end-user-network managers among my clients now multihome, and will continue to require multihomed service in future. In every case where the user's network is multihomed, the multiple independent connections are seen as crucial for maintenance of high availability of I find this funny. A number of studies have shown that if this is what you are after, multihoming and BGP is the wrong way to go - but never mind. the client's services to the public networks; and high availability is considered an absolute requirement for survival of the business. In some cases there are regulatory requirements which can result in civil or administrative sanctions (including, in the worst event, loss of operating licenses) if the services should be found unavailable for significant periods of time. Yes, it is possible, at least in theory, for commercial service providers to sustain the required level of availability, but most of my clients have found, much to their distress, that the US ISPs are almost uniformly incapable of doing so in practice. In almost every case, the administrative managers for these user networks are simply and flatly unwilling to put their businesses at the mercy of a single ISP. This worries me but is more a topic of Nanog, or my planned presentation at the Barcelona RIPE rather than IPng. Based on conversations with my clients, I cannot find it within the scope of my imagination (or, for that matter, of theirs) that these networks will give up the mutilhoming requirement at any time within the foreseeable future. Hmm. So if someone where to write up a draft on how to do resilient routing, with different alternatives and pros and cons, could you take this to your customers? Randy, is this something to add to the Barcelona topics? I think I have some slides to start this off(now all we need is a logo and we have a project) Home networks may be another matter, but I would give my eyeteeth to get a stable, portable (and, thereby, multihome-capable) IPv6 allocation for _my_ home network, as that network also supports supports my office and Notice that this comes at a price. You and me are willing to pay for this, but how many are? suspect that we will find increasing use of "home" networks for business activity, and increasing demand for stability of network locator Sure, but are you willing to pay for it? can't multihome. Based on experience with my client base, I cannot agree with the postulate that many networks will not find lack of multihome support a barrier to implementation of v6. I agree. Your client base seems to be exactly the target group. However, they also seems to be willing to pay for the service, as otherwise they will suffer financial loss that is higher than a days salary (if you can't log in from your home network). The current speculation about "what the users _really_ need" (as distin
RE: Enforcing unreachability of site local addresses
Alan E. Beard wrote: > ... > What think ye all? We are at an impass. The right outcome is that multi6 defines an approach that works for end sites, while scaling appropriately for the ISP concerns. The reality is that multi6 is off in the weeds rearchitecting the Internet, with no more hope of a useful outcome than the IRTF routing research wg has produced over the last N years. Unfortunately, this puts the ADs in a bind, because they would have a hard time justifing that the IPv6 wg should be tasked with defining an operational plan that an Operations Area wg is already tasked to do. It could be argued that since we are talking about allocations which conform to addr-arch-v3, the IETF is not the right place for the discussion anyway. The sticking point is that if we are talking about space other than 0x001, IANA would need to allocate that, which they are reluctant to do so without IESG buy-in, and since the IESG is in a bind, nothing can happen. Another data point for the discussion. At the NANOG earlier this week, Daniel Golding presented a discussion (http://www.nanog.org/mtg-0302/golding.html) about evolving the peering/inter-provider relationships along the lines where regional exchanges might reasonably become brokers between the regional ISPs & the transit providers. It is exactly that business model where PI approaches like Michele's or mine work well. Right now the IETF is stuck working on the assumption that we have to have a single global DFZ that knows all TE exception cases (even outside the scope of where they make sense), and that both the ISP & the end customers get to have full control of all the knobs. One could argue that it is the IETFs role to define the knobs, get out of the way, then watch and take the lessons learned as input for revising the function of said knobs. While it is frequently attempted, it is rarely wise to legislate operational behavior through the standards process. Despite all that, several people have continued to persue personal drafts with the expectation that eventually an appropriate forum will be found. Michele maintains a site with the active efforts at: http://arneill-py.sacramento.ca.us/ipv6mh/ I have a document that describes the situation and need for PI: http://www.tndh.net/~tony/ietf/ipv6piaddressusage-04.txt and a companion doc which describes one approach to a PI allocation scheme: http://www.tndh.net/~tony/ietf/ipv6piaddressformat-04.txt both of which I plan to refresh before the cutoff. Comments are welcome. Tony 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 [EMAIL PROTECTED]
RE: Enforcing unreachability of site local addresses
Dan, Margaret, et al: I have given some thought to the matters raised below. This note will address the questions raised by Dan in his first paragraph; the second paragraph will see a later response. Please be aware that the below should be considered, at its most ambitious, not more than a starting point for group discussion; it is not to be considered a formal proposal. AEB On Fri, 14 Feb 2003, Dan Lanciani wrote: > "Alan E. Beard" <[EMAIL PROTECTED]> wrote: > > |Yes, I think you are probably right in speculating that any technically > |sound mechanism which preserves the virtues of provider independence, > |portability, and stability in configuration of end-user-network devices > |will satisfy the functional requirements of the end-user community. It > |seems to be up to us to architect the mechanism(s). > > Any thoughts on how we might jump start some activity in this area? Over > the years I've tried the bottom-up approach by suggesting some possible > mechanisms, and I've tried the top-down approach by suggesting that we try > to reach consensus on how much overhead we are willing to accept in return > for the solution. The former generally provokes protests that the solution > is too complicated to sketch and the latter usually results in silence. How > can we get some serious discussion going? > [...] > > Dan Lanciani > ddl@danlan.*com > It seems to me that we have in recent weeks seen a shouting-match form of the top-down, how-much-penalty-are-we-willing-to-pay discussion, with one camp asserting loudly that the PA-with-aggregation scheme is strictly necessary for the operation of IPv6, and another group insisting vigorously that any address allocation scheme other than unrestricted PI will be inevitably and utterly fatal to the continued deployment of IPv6. This is roughly equivalent to: do we smother the baby now, or poison it when it reaches puberty? During this debate, most people with any reasonable sense of self-preservation (which immmediately excludes me) were cowering in gator holes, preferring the possibility of a confrontation with an enraged she-gator to the near certainty of an encounter with all the lead flying around out in the sawgrass. In both cases, the magnitude of the postulated adverse effect was deemed to be well beyond the pale, and the discussion subsided to a series of exasperated splutters. There are a number of paths we might explore to encourage some productive discusions. I will suggest below the outline of a sequence which seems to me attractive. First, we may wish to start a top-down discussion with the objective of assembling a list of functional objectives for the address allocation schemes which have been under discussion here. Please note that we have a possible charter problem here - more on that below. Once we have got rough concensus on the functional objectives, we can proceed to a bottom-up approach on mechanisms, and from there to specific proposals for standards, or BCP, or guidance to the registries. Now, we have a scope problem here, which is a result of the wording of the WG charter, and is further complicated by the instructions which came of out the Atlanta meeting. We probably need to consult Margaret before she concludes that we have taken the bit in our teeth (which we have) and are about to put at risk every horse and all the coaches in the staging yard (still undecided). At IETF 55 (Atlanta), floor discussions in the WG meeting indicated that a proposal to limit use of site-local address allocations was contingent, at least in the minds of many of the attendees, on making provision for some form of PI address space which is available to most (preferably _all_) networks. As this last issue did not fall within scope of any of the WG's defined work items, a decision was taken (how's that for passive voice?) to refer the matter to another area (SubIP or OAM, if my memory serves correctly) for consideration. What started in this WG as a discussion peripheral to the issue of restricting use of SL has now devolved into a reconsideration of the fundamental principles and assumptions underlying the address allocation practices for IPv6. This latter discussion is clearly beyond the scope of the current work items for this working group. However, the fundamental issues seem unwilling to fold their tents and steal away quietly into the night. As I read the WG charter, these matters are incontestably within the bounds of the charter, although not subsumed by any extant work item. IMHO, our discussions so far have identified a matter within the scope of the charter which urgently requires a resolution and requires further work toward that end. So far, we have, by dint of quite extraordinary self-restraint (yeah, right), avoided rogue status by confining our activities to disussion of the nature and scope of the perceived problems, rather than commencing formal work upon definiti
RE: RFC 3041 clarification requested
> I'm trying to understand what the following text means and > implies in Section 3.3 of RFC 3041: > >"Note: because multiple temporary addresses are generated from the > same associated randomized interface identifier, there is little > benefit in running DAD on every temporary address. This document > recommends that DAD be run on the first address generated from a > given randomized identifier, but that DAD be skipped on all > subsequent addresses generated from the same randomized interface > identifier." > > Does this refer to multiple addresses when the link has > multiple prefixes? Or when multiple temporary addresses are > generated in sequence? It says "addresses generated from the > given randomized identifier" so one might assume it means the > multiple prefix case. But on the other hand the randomized > identifier is also fed as history to the generation of new > addresses, so it might mean the sequence also. I think it means the multiple addresses when the link has multiple prefixes. > Additionally, I'm wondering how DAD works with RFC 3041. > The scheme appears to rely on the order in which addresses > are generated. On a network with two prefixes A and B two > nodes might not generate and test the addresses in the same > order. For instance, node 1 could test A:: and node 2 > could test B:: first. If the random values collide, > the collision apparently isn't detected and both nodes > proceed to use both A:: and B::. Or did I > miss something? Yes, this is a known bug in the spec. I think you should either run DAD on all your temporary addresses or none of them (if you trust your RNG). > Also, it wasn't clear to me whether link-local addresses are > generated for every new IID or not. If they are, RFC 2462 > rules in Section 5.4 apply and the collision problem may be > solved that way. (Or does it -- where does it say that > "first" in 3041 refers to the link-local address?) You do not generate link-local addresses for the new IIDs. And not site-local either. Just global addresses. Rich 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 [EMAIL PROTECTED]
RE: IPv6 WG Last Call on "IPv6 Global Unicast Address Format for the 2000::/3 Prefix"
Brian, > Brian E Carpenter wrote: > On balance, I prefer ducking the issue in the draft > we are discussing. If I get a /48 I have 16 bits for > subnet addressing and I'm happy, so why worry about > the acronym SLA? I have not been clear on this but I could not care less about the acronym itself. Killing the acronym is fine, what I think we need to preserve is the concept that there is a boundary there. > (but I still want to see an informational reference to > 3177 to ensure the paper trail is complete). Agree. 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 [EMAIL PROTECTED]
IPv6 MIB team: TCP-MIB in RFC2012 draft - tcpListenerTimeOuts
We have been looking into implementing TCP data from the version-neutral RFC2012 draft. We have a question about when the tcpListenerTimeOuts counter should be incremented given the following scenarios. We assume the counter should be incremented when the row is removed from the tcpConnectionTable while in the synReceived state _only if_ the removal was due to the retransmission of the SYN/ACK packets timing out. If the route from the client to the server is working but the route from the server back to the client is dropping packets, both the client and server's TCP/IP stacks will begin retransmitting packets. The client will retransmit the SYN packets and the server will retransmit the SYN/ACK reply. Because the SYN/ACK packets are dropped, this will continue until one or both sides time out. This can create unpredictable results as far as what the tcpListenerTimeOut counter will be. Here are some possible scenarios: a) The client and server retransmission intervals are approximately the same. The client times out first since it sent the first packet and sends a RST packet. The server receives the RST packet and removes the row from the tcpConnectionTable _before the server times out_. In this case the counter would _not_ be incremented at all. b) The client and server retransmission intervals are approximately the same. The client times out first since it sent the first packet and sends a RST packet. The server times out and removes the row from the tcpConnectionTable _before it processes the RST packet from the client_. In this case the counter would be incremented once. c) The client's retransmission interval have been configured to be longer than the server's intervals. The server might time out several times before the client eventually times out. When the server times out, it does send a RST packet, but because the packets are being dropped along this route, the client never receives the RST and continues to resend SYN packets. When the resent SYN is received by the server which just removed a row for the same local/remote IP address and port, it treats this packet as a new request and creates a new row in the tcpConnectionTable in synReceived state. The server could time out multiple times before the client times out causing the tcpListenerTimeOut counter to be incremented multiple times for a single connect() request. Is our understanding of when this counter is to be incremented correct? In the above scenarios, will the value reflect what the tcpListenerTimeOuts MIB object was intended to count? Thanks, Kristine Adamson IBM Communications Server for MVS: TCP/IP Development Internet e-mail:[EMAIL PROTECTED] 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 [EMAIL PROTECTED]
RFC 3041 clarification requested
Hi, I'm trying to understand what the following text means and implies in Section 3.3 of RFC 3041: "Note: because multiple temporary addresses are generated from the same associated randomized interface identifier, there is little benefit in running DAD on every temporary address. This document recommends that DAD be run on the first address generated from a given randomized identifier, but that DAD be skipped on all subsequent addresses generated from the same randomized interface identifier." Does this refer to multiple addresses when the link has multiple prefixes? Or when multiple temporary addresses are generated in sequence? It says "addresses generated from the given randomized identifier" so one might assume it means the multiple prefix case. But on the other hand the randomized identifier is also fed as history to the generation of new addresses, so it might mean the sequence also. Additionally, I'm wondering how DAD works with RFC 3041. The scheme appears to rely on the order in which addresses are generated. On a network with two prefixes A and B two nodes might not generate and test the addresses in the same order. For instance, node 1 could test A:: and node 2 could test B:: first. If the random values collide, the collision apparently isn't detected and both nodes proceed to use both A:: and B::. Or did I miss something? Also, it wasn't clear to me whether link-local addresses are generated for every new IID or not. If they are, RFC 2462 rules in Section 5.4 apply and the collision problem may be solved that way. (Or does it -- where does it say that "first" in 3041 refers to the link-local address?) Jari 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 [EMAIL PROTECTED]
Re: Flexible address policy on 2000::/3?
Mario Goebbels wrote: > > Does this imply that the 13bit TLA of the initial addressing scheme is > scrapped too? Yes. See http://www.ripe.net/ripe/docs/ipv6policy.html Brian 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 [EMAIL PROTECTED]
Flexible address policy on 2000::/3?
Does this imply that the 13bit TLA of the initial addressing scheme is scrapped too? Thanks for any info. -mg 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 [EMAIL PROTECTED]
Re: IPv6 WG Last Call on "IPv6 Global Unicast Address Format for the 2000::/3 Prefix"
On balance, I prefer ducking the issue in the draft we are discussing. If I get a /48 I have 16 bits for subnet addressing and I'm happy, so why worry about the acronym SLA? The RIRs have accepted the point (but I still want to see an informational reference to 3177 to ensure the paper trail is complete). Brian Michel Py wrote: > > Erik / ipv6 folk, > > > Erik Nordmark wrote: > > RFC 2374 contained an IPv6 allocation structure that > > included TLA (Top Level Aggregator) and NLA (Next > > Level Aggregator) which is formally made historic by > > this document. > > The TLA/NLA scheme has been replaced by an coordinated > > allocation policy defined by the Regional Internet > > Registries [REF]. Part of the motivations for obsoleting > > the TLA/NLA structure were technical, for instance there > > was concerns that it was not the technically best > > approach at this point in time on IPv6 deployment. > > Another part of the motivation was that the issues of > > how the IPv6 address space is managed is much more > > related to policy and to the the stewardship of the IP > > address space and routing table size that the RIRs have > > been managing for IPv4. It is likely that the RIRs > > policy will evolve as IPv6 deployment proceeds. > > The IETF has provided technical input to the RIRs (for > > example [RFC 3177]) that has been taken into account > > when defining the policy. > > I was re-reading your text, and I have additional comments. > > [disclaimer: I have stated before that it was fine by me, and this still > holds. If consensus is reached on the text you proposed the doc should > be shipped without further delays.] > > That being said, I have contradictory / ambiguous feelings about the > omission of "SLA". Here's the contradiction: > > - On one side, since you explicitly kill TLA and NLA but not SLA, it is > permitted to think that SLA is not completely dead, which suits me fine > since my position is that although moving it to policy was a good idea, > killing the notion of site boundary was not. > > - On the other side, if SLA is not dead it's not alive either, which > makes it a zombie I guess. This is not good, and one of these nights, > when the moon is full, it will rise from the grave like in Michael > Jackson's "thriller" and come haunt us. > > Therefore, we have three options for SLA: > 1. Don't change the text and keep it a zombie. > 2. Kill it (which I don't like). > 3. Spare it; the idea being that what we want to do is move it to policy > but don't kill the notion that a site boundary exists. This is what RIRs > call a "soft" or "semi-hard" boundary. > > Comments welcome. > > Michel. 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 [EMAIL PROTECTED]
Re: IPv6 WG Last Call on "IPv6 Global Unicast Address Format for the 2000::/3 Prefix"
OK for me Brian Michel Py wrote: > > Bob, > > > Bob Hinden wrote: > > [Erik's text] > > Any one else have comments on this change? > > Works for me. > > [the 2000::/3 prefix issue] > > Re-thinking it, my feelings are now that it would be good to remove it > from the title, and that indeed it is no different than the TLA/NLA > issue; in the same spirit than Erik's text, coining a sentence that says > in substance that FP 001 is dead although 2000::/3 still the only range > allocated for unicast use seems the way to go. In a sense, we could say > that the same way TLAs and NLAs have disappeared to become RIR policy, > FP 001 has disappeared to become IANA matter. > > Proposed title: "IPv6 Global Unicast Address Format" > > Proposed text: > > RFC2374 was the definition of addresses for Format Prefix 001 (2000::/3) > which is formally made historic by this document. Although as specified > in [ARCH] IANA should limit the IPv6 unicast address space to 2000::/3 > for now, IANA might allocate unassigned parts of the IPv6 address space > to Global Unicast later. > > Michel. 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 [EMAIL PROTECTED]
