Unique Local IPv6 Unicast Addresses
RFC 4193
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2012-08-22
|
09 | (System) | post-migration administrative database adjustment to the No Objection position for Margaret Wasserman |
2012-08-22
|
09 | (System) | post-migration administrative database adjustment to the No Objection position for Bill Fenner |
2012-08-22
|
09 | (System) | post-migration administrative database adjustment to the No Objection position for Sam Hartman |
2012-08-22
|
09 | (System) | post-migration administrative database adjustment to the No Objection position for Steven Bellovin |
2012-08-22
|
09 | (System) | post-migration administrative database adjustment to the Abstain position for Ted Hardie |
2012-08-22
|
09 | (System) | post-migration administrative database adjustment to the No Objection position for Russ Housley |
2012-08-22
|
09 | (System) | post-migration administrative database adjustment to the No Objection position for Alex Zinin |
2005-10-06
|
09 | Amy Vezza | State Changes to RFC Published from RFC Ed Queue by Amy Vezza |
2005-10-06
|
09 | Amy Vezza | [Note]: 'RFC 4193' added by Amy Vezza |
2005-10-04
|
09 | (System) | RFC published |
2005-03-30
|
09 | Amy Vezza | State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza |
2005-03-23
|
09 | Amy Vezza | IESG state changed to Approved-announcement sent |
2005-03-23
|
09 | Amy Vezza | IESG has approved the document |
2005-03-23
|
09 | Amy Vezza | Closed "Approve" ballot |
2005-03-23
|
09 | (System) | [Ballot Position Update] Position for Ted Hardie has been changed to Abstain from Discuss |
2005-03-23
|
09 | Margaret Cullen | [Ballot Position Update] Position for Margaret Wasserman has been changed to No Objection from Discuss by Margaret Wasserman |
2005-03-22
|
09 | Margaret Cullen | Note field has been cleared by Margaret Wasserman |
2005-03-22
|
09 | Margaret Cullen | State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Margaret Wasserman |
2005-03-11
|
09 | Margaret Cullen | Example comment for Mark. |
2005-03-11
|
09 | Margaret Cullen | Example comment for Mark. |
2005-03-11
|
09 | Margaret Cullen | State Changes to IESG Evaluation::AD Followup from IESG Evaluation::External Party by Margaret Wasserman |
2005-03-11
|
09 | Margaret Cullen | [Note]: 'Need RFC Editor note to address DNS concerns.' added by Margaret Wasserman |
2005-02-26
|
09 | Margaret Cullen | State Changes to IESG Evaluation::External Party from IESG Evaluation::AD Followup by Margaret Wasserman |
2005-02-26
|
09 | Margaret Cullen | [Note]: 'Plan to follow up on Mark Andrews'' concerns at DNS Directorate dinner in Minneapolis.' added by Margaret Wasserman |
2005-02-25
|
09 | Margaret Cullen | [Note]: 'Plan to follow up on Mark Andrews'' concerns at DNS Directorate dinner in Minneapolis. ' added by Margaret Wasserman |
2005-02-12
|
09 | Margaret Cullen | E-mail from Mark Andrews raising concerns with the level of DNS review this document has received: To: iesg@ietf.org, iab@iab.org From: Mark Andrews Date: Tue, … E-mail from Mark Andrews raising concerns with the level of DNS review this document has received: To: iesg@ietf.org, iab@iab.org From: Mark Andrews Date: Tue, 25 Jan 2005 11:54:05 +1100 Subject: Re: draft-ietf-ipv6-unique-local-addr-09.txt It was suggested that I send this to you. > Has anyone talked to the admins for IP6.INT / IP6.ARPA over > the impact this will have on the servers for IP6.INT / IP6.ARPA > if they don't do a AS 112 style deflection? > > Currently there are no words in draft-ietf-ipv6-unique-local-addr-09.tx t > saying that sites using these addresses should prevent > the reverse queries leaking out. I tried hard to get words > in but got squashed by the chairs. > > As far as I can see draft-ietf-ipv6-unique-local-addr-09.txt > has not been referred to either of the DNS working groups for > review but it as a DNS section that is woefully incomplete. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org |
2005-02-12
|
09 | Margaret Cullen | [Ballot discuss] Holding a discuss while we investigate Mark Andrews' concern that the document has not received adequate review from the DNS community. |
2005-02-12
|
09 | Margaret Cullen | [Ballot Position Update] Position for Margaret Wasserman has been changed to Discuss from Yes by Margaret Wasserman |
2005-01-24
|
09 | Sam Hartman | [Ballot Position Update] Position for Sam Hartman has been changed to No Objection from Discuss by Sam Hartman |
2005-01-24
|
09 | (System) | New version available: draft-ietf-ipv6-unique-local-addr-09.txt |
2004-12-29
|
09 | Sam Hartman | [Ballot discuss] In the interests of moving forward on this document, I'm picking up many of Ted's concerns. They are restated in my own words, … [Ballot discuss] In the interests of moving forward on this document, I'm picking up many of Ted's concerns. They are restated in my own words, and I will work with the authors, WG and ADs to resolve them. Updated again after discussions with the ADs. It is clear that there is a rough consensus in the IPV6 working group to advance this document as is. However the IESG has an important duty to judge the rough consensus of the entire IETF, particularly focusing on cross-area/cross-constituency issues and issues a working group might weight differently than other parts of the IETF. There is not rough consensus within the IETF to support one of the assumptions of this document. In particular, many have argued that the operational requirements that ULAs not be routed globally will not be followed. There is no rough consensus on this issue either way; strong opinions are held on both sides. In addition, concerns have been raised that deciding that ULAs with the l bit set to 0 are globally assigned is not justified before an allocation mechanism is designed. We get little in the way of value by making that decision now and limit our future flexibility. I had assumed we would want to confirm that there is a consensus to publish this document even if we believe that some ULAs may end up being globally routed. If there is such a consensus our path is easy; if not then we need to carefully consider the process to use. I had originally thought that polling the working group on this issue would be the best way forward. Margaret didn't think it would be possible to poll the working group; instead she proposed that we come up with text to present to the working group; if there are problems with consensus within the working group on the issue of publishing the document even if some addresses will be globally routed, these problems will show up as objections to the text. I'm OK with that approach or with discussing the issue with the working group. Here is a proposed path forward; other paths may be possible provided they also address both concerns. First, the document needs to be modified to leave any claims about semantics of l = 0 ULAs unspecified. This specification should define l = 1 ULAs and say nothing about l = 0 ULAs other than that they are reserved. Next, the document needs to reflect the fact that there is a concern that the routing advice will not be followed. The document must take no position on how reasonable this concern is; there is not a consensus for any such position within the IETF community even though there may be such a consensus in the IPV6 working group. The document should discuss reasons why the routing requirements should be followed both from the standpoint of the global Internet community and from the standpoint of someone who wishes their ULA routed. The document should also discuss potential problems that may result if ULAs do tend to become globally routed, although I think this discussion is implied by a discussion of why the global Internet community wants the routing requirements followed. |
2004-12-22
|
09 | Sam Hartman | [Ballot discuss] In the interests of moving forward on this document, I'm picking up many of Ted's concerns. They are restated in my own words, … [Ballot discuss] In the interests of moving forward on this document, I'm picking up many of Ted's concerns. They are restated in my own words, and I will work with the authors, WG and ADs to resolve them. It is clear that there is a rough consensus in the IPV6 working group to advance this document as is. However the IESG has an important duty to judge the rough consensus of the entire IETF, particularly focusing on cross-area/cross-constituency issues and issues a working group might weight differently than other parts of the IETF. There is not rough consensus within the IETF to support one of the assumptions of this document. In particular, many have argued that the operational requirements that ULAs not be routed globally will not be followed. There is no rough consensus on this issue either way; strong opinions are held on both sides. In addition, concerns have been raised that deciding that ULAs with the l bit set to 0 are globally assigned is not justified before an allocation mechanism is designed. We get little in the way of value by making that decision now and limit our future flexibility. Here is a proposed path forward; other paths may be possible provided they also address both concerns. First we should confirm that there is a consensus to publish this document even if we believe that some ULAs may end up being globally routed. If there is such a consensus our path is easy; if not then we need to carefully consider the process to use. Second, the document needs to be modified to leave any claims about semantics of l = 0 ULAs unspecified. This specification should define l = 1 ULAs and say nothing about l = 0 ULAs other than that they are reserved. Next, the document needs to reflect the fact that there is a concern that the routing advice will not be followed. The document must take no position on how reasonable this concern is; there is not a consensus for any such position within the IETF community even though there may be such a consensus in the IPV6 working group. The document should discuss reasons why the routing requirements should be followed both from the standpoint of the global Internet community and from the standpoint of someone who wishes their ULA routed. The document should also discuss potential problems that may result if ULAs do tend to become globally routed. |
2004-12-22
|
09 | Sam Hartman | [Ballot discuss] It is clear that there is a rough consensus in the IPV6 working group to advance this document as is. However the IESG … [Ballot discuss] It is clear that there is a rough consensus in the IPV6 working group to advance this document as is. However the IESG has an important duty to judge the rough consensus of the entire IETF, particularly focusing on cross-area/cross-constituency issues and issues a working group might weight differently than other parts of the IETF. There is not rough consensus within the IETF to support one of the assumptions of this document. In particular, many have argued that the operational requirements that ULAs not be routed globally will not be followed. There is no rough consensus on this issue either way; strong opinions are held on both sides. In addition, concerns have been raised that deciding that ULAs with the l bit set to 0 are globally assigned is not justified before an allocation mechanism is designed. We get little in the way of value by making that decision now and limit our future flexibility. Here is a proposed path forward; other paths may be possible provided they also address both concerns. First we should confirm that there is a consensus to publish this document even if we believe that some ULAs may end up being globally routed. If there is such a consensus our path is easy; if not then we need to carefully consider the process to use. Second, the document needs to be modified to leave any claims about semantics of l = 0 ULAs unspecified. This specification should define l = 1 ULAs and say nothing about l = 0 ULAs other than that they are reserved. Next, the document needs to reflect the fact that there is a concern that the routing advice will not be followed. The document must take no position on how reasonable this concern is; there is not a consensus for any such position within the IETF community even though there may be such a consensus in the IPV6 working group. The document should discuss reasons why the routing requirements should be followed both from the standpoint of the global Internet community and from the standpoint of someone who wishes their ULA routed. The document should also discuss potential problems that may result if ULAs do tend to become globally routed. |
2004-12-22
|
09 | Sam Hartman | [Ballot Position Update] Position for Sam Hartman has been changed to Discuss from No Objection by Sam Hartman |
2004-12-08
|
09 | Ted Hardie | [Ballot discuss] Since writing the initial DISCUSS on this there has been an extensive discussion of the issue on ARIN's PPML list, on NANOG's discussion … [Ballot discuss] Since writing the initial DISCUSS on this there has been an extensive discussion of the issue on ARIN's PPML list, on NANOG's discussion list, and within the IESG. ARIN's chair declined a request by a member for ARIN to issue a message on behalf of its membership to the IESG, asking instead that the IESG take the individual messages sent into account. My thinking on this has certainly changed in response to those public discussions and I have quoted several messages from there which had particular force for me. I have not, however, tried to summarize the whole discussion set and encourage the IESG, the authors, and working group to read the threads for themselves. The salient NANOG archives start at http://www.merit.edu/mail.archives/nanog/2004-11/ and the PPML archives are at http://www.arin.net/mailing_lists/ppml/. Note that there has been a specific proposal for ARIN to allocate PI space in the context of this discussion. I do not know if other RIRs have had similar discussions or whether similar proposals have been floated to them. My original DISCUSS raised three main issues: the reservation of two /8s where the mechanism for assignment in one was postponed; the ambiguity presented by the document's focus on "site" (using a term it chose not to define); and the problems posed by discussing something as "local" while providing for inter-site routing of these prefixes. During the course of the original write-up, I said: "If these are mostly-bogons, but might be valid based on inter-provider agreement, then this is really a small bit of provider-neutral space with a mechanism for self-assignment within it. That's a valuable thing, maybe a more valuable thing, than what this document says it is doing". During the course of discussions, Paul Vixie and Owen DeLong have argued along the same lines and have argued that the routing policy presumed by this document will not remain in force. The document puts forward the routing policy as "They are not expected to be routable on the global Internet" in the Introduction and goes on in section 4.1 to say: "The default behavior of exterior routing protocol sessions between administrative routing regions must be to ignore receipt of and not advertise prefixes in the FC00::/7 block. A network operator may specifically configure prefixes longer than FC00::/7 for inter-site communication." Paul Vixie commented on this point on the PPML list, saying ++++ i don't think it'll work like you're saying. let's say ULA goes into general use and that a number of enterprises who are all customers of a set of ISP's decide that rather than tunnelling, they'd like their shared set of ISP's to "just route the ULA prefixes please." by enterprise i'm talking Ford and GM and Daimler and their rust-belt supply network, or perhaps Wal-Mart and its offshore vendor network. we know what the ISP's will say: "yes, ma'am, and would you like fries with that?" now let's assume that someone wants to enter one of these enterprise frays and their ISP is not "part of the collective". the ISP in question will not want to allow sheer force to be applied to this customer, so they'll join the collective either by direct peering or by tunnels. lather, rinse, repeat. human action (per von mises and others) automatically turns ULA into PI over time, with increasing horizons and therefore decreasing margins between what it means to be "unique" and what it means to be "global". you cannot legislate human nature, but you can make it take perverse turns to get where it's going, and make it take longer to get there, if you want. i don't want us to do that or even try to do that. instead, let's just recognize that a far larger segment of the enterprise community needs PI than was previously believed, and transform all ULA arguments to date into "PI reform" arguments, ++++++ Owen's point was similar: ++++ Market forces aren't driving a desire for ULA. They are driving a desire for cost effective globally unique addresses. A good part of the market does not care about routability or not of those addresses. A meaningful part of the market does. ULA will meet the needs of the former, but, not the latter. Globally unique address assignments to end users with a rational policy (the v6 equivalent of 2002-3 at say the /48 or /56 level) would meet the needs being addressed by ULA and needs not being met by the ULA proposal. (Unattributed quote in Owen's original) >As for the ingress filtering issue, education and contract terms are >two good answers. I'd like to see network operators considering >ingress as part of their aggregation router buying decisions, of >course. Contract terms are a negotiation. As soon as dollars are available for the sake of abandoning an entirely artificial limitation on the use of addresses, guess which way that negotiation will go. We'd all love to see that, but, regardless of the capabilities of the router, the reality is that when a customer dangles enough dollars in front of an ISP for advertising their non-routable space that will do no harm by being advertised to the rest of the internet, they're going to do the following: 1. Warn the customer this may not work out so well for them. 2. Do everything they can to get the route accepted. (If you think this will actually be hard, think again) 3. Take the money. As to why 2 won't be hard: Think of it this way... Each provider is going to be faced with such customers fairly quickly. They're not going to come to the techies and ask why not and go gently into that good night. The sales people are going to see $$ for doing this at each and every ISP and they're going to drive negotiations between management at the providers to trade these "harmless" routes. This decision will not be made by the operational community, but, inflicted on it by management seeing $$ for doing so. Owen noted in a different message: As I see it, the only effective way to prevent the issue is to change the general allocation policy to meet all needs and recognize that globally unique space is globally unique space from a technology perspective. From a social engineering perspective, any such distinctions are purely artificial, and, will be recognized as such and removed by market economics. (Or, to put it in terms IETF may better understand: In the long run, such limitations will be viewed as damage and simply routed around.) ++++++++++++++++ I actually believe the document is clear that it is describing provider independent space, but that Paul and Owen mean "PI space" to include the right of its holder to determine the routing policy in the normal way, which includes negotiations with peers and upstream providers on what will be carried. My interpretation of their argument is, in other words, that the routing policy set out by this document will not remain in force. I am, frankly, convinced by their arguments that the association of this routing policy with these prefixes is not permanent. There are several routes forward from that conclusion. The first would be to change the specification such that there was a serious technical impediment to this space being routed on the Internet. The most obvious such impediment would be lack of uniqueness, and the problems with that are well known. I cannot personally think of other changes which would imply such an impediment and which would not have similar problems. I suspect, in other words, that this way forward is closed to us. A second route forward is to assume that the rate of movement away from this routing policy can be managed such that the appearance of this PI space in the global V6 routing table will be slow enough not to cause problems. A corollary to that is probably that the document should have stronger language describing the problems unrestrained growth would cause, as at least some actors will be moved to protect the commons. Given that the focus of the document is unmanaged assignment, relying on those arguments alone to manage growth seems somewhat problematic, though some would argue that the maximum number of additional entries is limited because the size of the initial allocation avoids announcement of multiple prefixes. The first route forward attempts to keep ULAs local; the second allows them to drift from local to PI over time. A third route forward would be to start from the idea that the real need is for "PI space" as Owen and Paul have described it--allocation of prefixes which are provider independent and whose routing policies are determined in the normal way. If we are convinced that the routing table can handle the introduction of the prefixes which will not remain local (and many, obviously, would), this seems personally to me the best way forward, and the question then becomes whether this allocation mechanism is adequate given the *likelihood* of global announcement rather than the presumption of locality. If we are not convinced that the routing table can handle it, then we need to ask ourselves whether it will be possible for it to handle it within the time scale implied by the drift in the second route and, if not, what we can do to make them match. I recognize that I am, at this point, attempting to convince the authors and working group to take this document back to a question of assumptions, and that, as with site local, this is painful. I hope, however, that the views of the operational community expressed in the lists mentioned above are sufficiently strong that the working group will agree. I know Stephen Sprunk has followed those discussions in some detail and others may have as well; in other words, I hope the conversation has already started. Whether or not the assumptions are questioned, the issue I raised related to the allocation of a /7 here remains. Though the document has now changed to use a /7 and an "L" bit rather than two /8s, the fundamental issue is still in play. The original reserved a /8 for a purpose (central assignment for ULAs) for which community consensus has not yet been judged. This document reserves one of the states of L for a purpose for which community consensus has not yet been judged. If the L bit is retained, I strongly recommend defining only the "0" state, and leaving the "1" state to be defined when community consensus on the later mechanism has been attained. One might imagine, for example, that the decision to assume that these would hit the routing table might make folks nervous enough of collision that the extra trillion derived from using both 0 and 1 for self-assignment would seem wise :). |
2004-12-05
|
09 | Margaret Cullen | Sent follow-up message to Ted, asking him to clear the final discuss or clarify remaining issues. |
2004-12-05
|
09 | Margaret Cullen | Note field has been cleared by Margaret Wasserman |
2004-12-03
|
09 | (System) | Removed from agenda for telechat - 2004-12-02 |
2004-12-02
|
09 | Amy Vezza | State Changes to IESG Evaluation::AD Followup from IESG Evaluation by Amy Vezza |
2004-12-02
|
09 | Amy Vezza | [Note]: 'Ted, Bill and Alex, could you please check if your concerns have been addressed? If not, please let me know what issues remain. Thanks. … [Note]: 'Ted, Bill and Alex, could you please check if your concerns have been addressed? If not, please let me know what issues remain. Thanks. Question for all: What should we do regarding possible ARIN issues with this document?' added by Amy Vezza |
2004-12-02
|
09 | Thomas Narten | [Ballot Position Update] New position, No Objection, has been recorded for Thomas Narten by Thomas Narten |
2004-12-02
|
09 | Sam Hartman | [Ballot Position Update] New position, No Objection, has been recorded for Sam Hartman by Sam Hartman |
2004-12-01
|
09 | Bill Fenner | [Ballot Position Update] Position for Bill Fenner has been changed to No Objection from Discuss by Bill Fenner |
2004-12-01
|
09 | Bert Wijnen | [Ballot Position Update] New position, No Objection, has been recorded for Bert Wijnen by Bert Wijnen |
2004-12-01
|
09 | Harald Alvestrand | [Ballot comment] Reviewed by Michael Patton, Gen-ART His review of -08: OK. I have enough other work that I'm not going to do a full … [Ballot comment] Reviewed by Michael Patton, Gen-ART His review of -08: OK. I have enough other work that I'm not going to do a full re-review, but I went through my earlier review and checked all of the items I found then and they all seem to have been adequately addressed. |
2004-11-30
|
09 | Alex Zinin | [Ballot Position Update] Position for Alex Zinin has been changed to No Objection from Discuss by Alex Zinin |
2004-11-29
|
09 | Margaret Cullen | [Note]: 'Ted, Bill and Alex, could you please check if your concerns have been addressed? If not, please let me know what issues remain. Thanks. … [Note]: 'Ted, Bill and Alex, could you please check if your concerns have been addressed? If not, please let me know what issues remain. Thanks. Question for all: What should we do regarding possible ARIN issues with this document?' added by Margaret Wasserman |
2004-11-29
|
08 | (System) | New version available: draft-ietf-ipv6-unique-local-addr-08.txt |
2004-11-28
|
09 | Margaret Cullen | Placed on agenda for telechat - 2004-12-02 by Margaret Wasserman |
2004-11-28
|
09 | Margaret Cullen | State Changes to IESG Evaluation from IESG Evaluation::AD Followup by Margaret Wasserman |
2004-11-28
|
09 | Margaret Cullen | [Note]: 'The -08 version has been submitted that should address most (or all?) of the outstanding discusses, but hasn''t been posted yet. In the meantime, … [Note]: 'The -08 version has been submitted that should address most (or all?) of the outstanding discusses, but hasn''t been posted yet. In the meantime, see: http://people.nokia.net/~hinden/ULA/draft-ietf-ipv6-unique-local-addr-08.txt Ted, Bill and Alex, could you please check if your concerns have been addressed? If not, please let me know what issues remain. Thanks. Question for all: What should we do regarding possible ARIN issues with this document? ' added by Margaret Wasserman |
2004-11-11
|
09 | Steven Bellovin | [Ballot Position Update] Position for Steve Bellovin has been changed to No Objection from Discuss by Steve Bellovin |
2004-10-25
|
09 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2004-10-25
|
07 | (System) | New version available: draft-ietf-ipv6-unique-local-addr-07.txt |
2004-10-15
|
09 | Amy Vezza | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Amy Vezza |
2004-10-14
|
09 | Allison Mankin | [Ballot Position Update] New position, No Objection, has been recorded for Allison Mankin by Allison Mankin |
2004-10-14
|
09 | Bill Fenner | [Ballot discuss] Section 3.1 says that the global ID is 41 bits. Section 3.2.2 says to use the lower 40 bits of an MD5 calculation … [Ballot discuss] Section 3.1 says that the global ID is 41 bits. Section 3.2.2 says to use the lower 40 bits of an MD5 calculation as the global ID. There is an implicit "and set the high bit to 1". I'd suggest either calling the 8th bit of the address the "global/local" bit and calling the global ID 40 bits, or explicitly stating that the high bit is set in local assignments - otherwise you'll get an implementor who puts 3.2.2 together with 3.1, missing the implicit statement in 3.2, and gets a locally generated local address that's in fc00::/8. |
2004-10-14
|
09 | Bill Fenner | [Ballot Position Update] New position, Discuss, has been recorded for Bill Fenner by Bill Fenner |
2004-10-14
|
09 | Jon Peterson | [Ballot Position Update] New position, No Objection, has been recorded for Jon Peterson by Jon Peterson |
2004-10-13
|
09 | Alex Zinin | [Ballot discuss] 1. It would be useful to give a definition of a "site", keeping the routing aspects in mind. 2. Section 4 "Routing" … [Ballot discuss] 1. It would be useful to give a definition of a "site", keeping the routing aspects in mind. 2. Section 4 "Routing" > Any router that is used between sites must be configured to filter > out any incoming or outgoing Local IPv6 unicast routes. The > exception to this is if specific /48 or longer IPv6 local unicast > routes have been configured to allow for inter-site communication. > If BGP is being used at the site border with an ISP, the default BGP > configuration must be set to to keep any Local IPv6 address prefixes > from being advertised outside of the site or for these prefixes to be > learned from another site. The exception to this is if there are > specific /48 or longer routes created for one or more Local IPv6 > prefixes. In the above statement, is it assumed that BGP has visibility to site boundaries, or that it is always used for inter-site connectivity and never for intra-site? The reason for the question is that requiring default BGP behavior to be as described above calls for site awareness and implementation change. If the real intention is that BGP should be _manually_ _configured_ to filter out local prefixes, the text needs to be changed. It should be noted that if an link state IGP (OSPF/IS-IS) is used for routing between sites, which is a possibility in enterprise networks, a single site should be contained within a single IGP domain or area, as prefix distribution within a link-state area cannot be controlled. Section 6.0 > Site border routers should install a "reject" route for the Local > IPv6 prefix FC00::/7. This will ensure that packets with Local IPv6 > destination addresses will not be forwarded outside of the site via a > default route. Site border routers should respond with the > appropriate ICMPv6 Destination Unreachable message to inform the > source that the packet was not forwarded [ICMPV6]. This feedback is > important to avoid transport protocol timeouts. > > Site border routers and firewalls should not forward any packets with > Local IPv6 source or destination addresses outside of the site unless > they have been explicitly configured with routing information about > specific /48 or longer Local IPv6 prefixes. The default behavior of > these devices should be to install a "reject" route for these > prefixes. Site border routers should respond with the appropriate > ICMPv6 Destination Unreachable message to inform the source that the > packet was not forwarded. There's an overlap between the two paras above. The first para covers the destination address check. The second tries to cover both destination and source. First, I'd like to understand exactly what "outside of the site" means in this section. Does it mean a non-FC00::/7 IPv6 dst address, or a FC00::/7 address with another global-ID, or both? Second, do you realize that checking the source address will require changes to the router's forwarding algorithm compared to how global addresses are handled? Third, it is a current operational practice to disable ICMP unreachables for reject routes to avoid ICMP storms cause by infected machines' scanning the network. I suggest we change it to something like "MAY send, MUST be configurable, and MUST be off by default". From rtg-dir (Radia): The document should be more clear about what the desired behavior is for the case where two or more sites are connected together. |
2004-10-13
|
09 | Alex Zinin | [Ballot discuss] 1. It would be useful to give a definition of a "site", keeping the routing aspects in mind. 2. Section 4 "Routing" … [Ballot discuss] 1. It would be useful to give a definition of a "site", keeping the routing aspects in mind. 2. Section 4 "Routing" > Any router that is used between sites must be configured to filter > out any incoming or outgoing Local IPv6 unicast routes. The > exception to this is if specific /48 or longer IPv6 local unicast > routes have been configured to allow for inter-site communication. > If BGP is being used at the site border with an ISP, the default BGP > configuration must be set to to keep any Local IPv6 address prefixes > from being advertised outside of the site or for these prefixes to be > learned from another site. The exception to this is if there are > specific /48 or longer routes created for one or more Local IPv6 > prefixes. In the above statement, is it assumed that BGP has visibility to site boundaries, or that it is always used for inter-site connectivity and never for intra-site? The reason for the question is that requiring default BGP behavior to be as described above calls for site awareness and implementation change. If the real intention is that BGP should be _manually_ _configured_ to filter out local prefixes, the text needs to be changed. It should be noted that if an link state IGP (OSPF/IS-IS) is used for routing between sites, which is a possibility in enterprise networks, a single site should be contained within a single IGP domain or area, as prefix distribution within a link-state area cannot be controlled. Section 6.0 > Site border routers should install a "reject" route for the Local > IPv6 prefix FC00::/7. This will ensure that packets with Local IPv6 > destination addresses will not be forwarded outside of the site via a > default route. Site border routers should respond with the > appropriate ICMPv6 Destination Unreachable message to inform the > source that the packet was not forwarded [ICMPV6]. This feedback is > important to avoid transport protocol timeouts. > > Site border routers and firewalls should not forward any packets with > Local IPv6 source or destination addresses outside of the site unless > they have been explicitly configured with routing information about > specific /48 or longer Local IPv6 prefixes. The default behavior of > these devices should be to install a "reject" route for these > prefixes. Site border routers should respond with the appropriate > ICMPv6 Destination Unreachable message to inform the source that the > packet was not forwarded. There's an overlap between the two paras above. The first para covers the destination address check. The second tries to cover both destination and source. First, I'd like to understand exactly what "outside of the site" means in this section. Does it mean a non-FC00::/7 IPv6 dst address, or a FC00::/7 address with another global-ID, or both? Second, do you realize that checking the source address will require changes to the router's forwarding algorithm compared to how global addresses are handled? Third, it is a current operational practice to disable ICMP unreachables for reject routes to avoid ICMP storms cause by infected machines' scanning the network. I suggest we change it to something like "MAY send, MUST be configurable, and MUST be off by default". |
2004-10-13
|
09 | Alex Zinin | [Ballot Position Update] New position, Discuss, has been recorded for Alex Zinin by Alex Zinin |
2004-10-13
|
09 | David Kessens | [Ballot Position Update] New position, No Objection, has been recorded for David Kessens by David Kessens |
2004-10-13
|
09 | Harald Alvestrand | [Ballot comment] Reviewed by Michael Patton, Gen-ART Things that should get fixed, from his review: The last paragraph of Section 3.2 is self-contradictory. It says … [Ballot comment] Reviewed by Michael Patton, Gen-ART Things that should get fixed, from his review: The last paragraph of Section 3.2 is self-contradictory. It says this document only defines the centrally assigned addresses and that the centrally assigned addresses are defined in another document. I believe it meant to say that this document only defines the locally assigned addresses. Minor comments, not enough to require a rev of the document...but since the preceding does, these could be considered as well. In section 3,2 where it describes the "Two assignment methods", I would suggest use of the terms "guaranteed unique" and "probabilistically unique" to describe their properties. I could offer specific wording, if desired. This document references RFC1750 (as [RANDOM]). A new version (which I understand to be greatly improved) is in development (currently it's draft-eastlake-randomness2-08.txt). If that's almost ready to go, I'd suggest making this draft reference that. But, it's a normative reference, so I don't recommend holding this document up very long waiting for it. Perhaps if draft-eastlake-randomness2 makes it into the front of the RFC Editor queue before this one comes out the end an RFC number can be assigned and used in the RFC version of this draft. In section 3.2.3 second paragraph. To be pedantic it's not the fact that the IDs are chosen randomly that makes collisions possible, but rather the fact that they are chosen independently. I'm sure that this difference probably won't matter to most readers, but the lead in on that paragraph could be changed to "Since global IDs are chosen independently, ..." to make it slightly more rigorously correct. In the fourth paragraph of Section 4.0, the grouping on the long sentence is ambiguous and can result in two distinct meanings being deduced (and the several typos don't help). One of those meanings is clearly nonsense to anyone with routing clue, but just to be sure nobody uses that meaning, I suggest this rewording: If BGP is being used at the site border with an ISP, the default BGP configuration must filter out any Local IPv6 address prefixes, both incoming and outgoing. It must be set both to keep any Local IPv6 address prefixes from being advertised outside of the site as well as to keep these prefixes from being learned from another site. The exception to this is if there are specific /48 or longer routes created for one or more Local IPv6 prefixes. I don't actually think that [POPUL] is a Normative reference, since it's only used in "why we think this is sufficient" contexts. The reference isn't used in "how to implement" contexts. |
2004-10-13
|
09 | Harald Alvestrand | [Ballot Position Update] New position, No Objection, has been recorded for Harald Alvestrand by Harald Alvestrand |
2004-10-13
|
09 | Russ Housley | [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss by Russ Housley |
2004-10-13
|
09 | Russ Housley | [Ballot discuss] I changed my position to NO-OBJECTION, and moved the text of my original position to a comment. |
2004-10-13
|
09 | Russ Housley | [Ballot Position Update] Position for Russ Housley has been changed to Discuss from No Objection by Russ Housley |
2004-10-13
|
09 | Russ Housley | [Ballot comment] Section 3.2.2 makes use of MD5. While MD5 is probably fine for this application, I strongly prefer SHA-1. I propose the replacement … [Ballot comment] Section 3.2.2 makes use of MD5. While MD5 is probably fine for this application, I strongly prefer SHA-1. I propose the replacement of steps 4) and 5) with the following: 4) Compute an SHA-1 digest on the key as specified in [FIPS, SHA1]; the resulting value is 160 bits. 5) Use the least significant 40 bits as the Global ID. [FIPS] Federal Information Processing Standards Publication (FIPS PUB) 180-1, Secure Hash Standard, 17 April 1995. [SHA1] D. Eastlake 3rd and P. Jones, US Secure Hash Algorithm 1 (SHA1), RFC 3174, September 2001. Section 3.2.2 provides an algorithm, but not source code. I think the title of the section should be changed. Global change: s/IPSEC/IPsec/ |
2004-10-13
|
09 | Russ Housley | [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss by Russ Housley |
2004-10-13
|
09 | Russ Housley | [Ballot comment] Section 3.2.2 makes use of MD5. While MD5 is probably fine for this application, I strongly prefer SHA-1. I propose the replacement … [Ballot comment] Section 3.2.2 makes use of MD5. While MD5 is probably fine for this application, I strongly prefer SHA-1. I propose the replacement of steps 4) and 5) with the following: 4) Compute an SHA-1 digest on the key as specified in [FIPS, SHA1]; the resulting value is 160 bits. 5) Use the least significant 40 bits as the Global ID. [FIPS] Federal Information Processing Standards Publication (FIPS PUB) 180-1, Secure Hash Standard, 17 April 1995. [SHA1] D. Eastlake 3rd and P. Jones, US Secure Hash Algorithm 1 (SHA1), RFC 3174, September 2001. Section 3.2.2 provides an algorithm, but not source code. I think the title of the section should be changed. Global change: s/IPSEC/IPsec/ |
2004-10-12
|
09 | Ted Hardie | [Ballot discuss] There's a lot to this, but one of the biggest issues is that the document reserves for FC00::/8 for central assignment, but says: … [Ballot discuss] There's a lot to this, but one of the biggest issues is that the document reserves for FC00::/8 for central assignment, but says: This document only allocates the prefix (FC00::/8) for centrally assigned local IPv6 addresses. The characteristics and technical allocation requirements for centrally assigned Local IPv6 addresses will be defined in a separate document. This strikes me as extraordinarily unwise. Once allocated, this prefix is gone into the equivalent of RFC 1918 space, and no matter what wisdom we provide on how to global allocate addresses, people are free to be as stupid about this as they were about net 10. We can't stop people shooting themselves, but handing them a gun and saying "safety manual to come" seems a bit much. What actual harm is there in waiting on this assignment until the documents are written? The next big issue with this is that it never defines what it means by "site". The text about looks like this text could be inferred as "a site for the purposes of this identifier is the set of interconnected networks which agree to route these local addresses." Yeah, it's circular, but it makes clear that it is the agreement to route them that defines a site for the purpose of a particular local address. There are, of course, other potential definitions of site (some implied by the 3.2 discussion of the split between those who might use the two different /8s, for example), but they are not explored. An explicit definition of the term looks like an awfully good idea to me, if only to prevent later exploration of that space. I'm also concerned about this issue in the context of the "inter-site" routing discussion, for example, here: Any router that is used between sites must be configured to filter out any incoming or outgoing Local IPv6 unicast routes. The exception to this is if specific /48 or longer IPv6 local unicast routes have been configured to allow for inter-site communication. This gets complicated quickly. If these are bogons, it is hard enough to get them well filtered. If these are mostly-bogons, but might be valid based on inter-provider agreement, then this is really an allocation of a small bit of provider-neutral space with a mechanism for self-assignment within it. That's a valuable thing, maybe a more valuable thing, than what this document says its doing. But I don't think you can conceive of them as "local", then talk about inter-site passage of routing data without using an overlay network construct to define the "site" as crossing what might be some other boundary. In the context of 6.0, the authors might want to review the recent posting by Sean Donelan on NANOG found here: http://www.merit.edu/mail.archives/nanog/msg01741.html The line "too many boxes still crumble" makes me wonder who will be able to do a real job of this. After all, a "reject" route can still leave packets using these as source addresses being sent out into the wild. They may not come back, but that doesn't help the global Internet quite as much as the operators might like. The advice in paragraph 2 of Section 8 seems like it is totally contrary to the advice in the paragraph before it, possibly because they mean "use split DNS" but don't say it. Getting this clear might also help clarify the advice in 9.0. Speaking of which, let me channel Randy Bush a moment as I read this: - Nodes that are to be limited to only communicate with other nodes in the site: These nodes should be set to only autoconfigure Local IPv6 addresses via [ADDAUTO] or to only receive Local IPv6 addresses via [DHCP6]. Note: For the case where both global and Local IPv6 prefixes are being advertised on a subnet, this will require a switch in the devices to only autoconfigure Local IPv6 addresses. "Oh! I thought we were talking about the *Internet*" I have no idea what the "Note:" section is supposed to mean, and I'm not sure I care. The idea that this set of steps will prevent confusion between differently scoped addresses seems, at best, a fond hope. And this statement in the "Reasons" section: - Applications can treat these addresses in an identical manner as any other type of global IPv6 unicast addresses. seems contradictory. If an application can expect to find, store, and cache these addresses in a consistent DNS in case one and not in case two, the two cases are not identical. Or so it seems to me. |
2004-10-12
|
09 | Ted Hardie | [Ballot Position Update] New position, Discuss, has been recorded for Ted Hardie by Ted Hardie |
2004-10-11
|
09 | Russ Housley | [Ballot comment] Section 3.2.2 provides an algorithm, but not source code. I think the title of the section should be changed. Global change: … [Ballot comment] Section 3.2.2 provides an algorithm, but not source code. I think the title of the section should be changed. Global change: s/IPSEC/IPsec/ |
2004-10-11
|
09 | Russ Housley | [Ballot discuss] Section 3.2.2 makes use of MD5. While MD5 is probably fine for this application, I strongly prefer SHA-1. I propose the replacement … [Ballot discuss] Section 3.2.2 makes use of MD5. While MD5 is probably fine for this application, I strongly prefer SHA-1. I propose the replacement of steps 4) and 5) with the following: 4) Compute an SHA-1 digest on the key as specified in [FIPS, SHA1]; the resulting value is 160 bits. 5) Use the least significant 40 bits as the Global ID. [FIPS] Federal Information Processing Standards Publication (FIPS PUB) 180-1, Secure Hash Standard, 17 April 1995. [SHA1] D. Eastlake 3rd and P. Jones, US Secure Hash Algorithm 1 (SHA1), RFC 3174, September 2001. |
2004-10-11
|
09 | Russ Housley | [Ballot Position Update] New position, Discuss, has been recorded for Russ Housley by Russ Housley |
2004-10-11
|
09 | Steven Bellovin | [Ballot discuss] Section 3.2.3 is confusing. It presents an analysis of the probability of a collision in terms of the number of "connections" between the … [Ballot discuss] Section 3.2.3 is confusing. It presents an analysis of the probability of a collision in terms of the number of "connections" between the networks. You don't define networks, and you don't define what the probability means. You need to state it this way: "for a given network with one or more random global ID that has interconnections to other such networks, having in aggregate a total of N such IDs, the probability that that two or more of these N IDs will collide is ..." As written, the text can be interpreted to be talking about TCP connections or the probability of a collision anywhere in the Internet. (My wording takes into account the possiblity of more than one prefix per network, per 3.3) Please justify the ban on AAAA records for such addresses. In most cases, it's desirable to have all non-link-local addresses for a host in the DNS, because it lets applications use a uniform mechanism for finding a host. The alternative would seem to be two-faced DNS servers, a concept that has never worked that well. (Do the appropriate DNS WGs concur with this recommendation?) By contrast, I agree that PTR records should not be used, since it would create a large number of non-aggregatable delegations in the inverse map tree. But that should be explained, too. |
2004-10-11
|
09 | Steven Bellovin | [Ballot Position Update] New position, Discuss, has been recorded for Steve Bellovin by Steve Bellovin |
2004-10-04
|
09 | Scott Hollenbeck | [Ballot Position Update] Position for Scott Hollenbeck has been changed to No Objection from Undefined by Scott Hollenbeck |
2004-10-04
|
09 | Scott Hollenbeck | [Ballot comment] Section 7 says that "AAAA and PTR records for locally assigned local IPv6 addresses are not recommended to be installed in the global … [Ballot comment] Section 7 says that "AAAA and PTR records for locally assigned local IPv6 addresses are not recommended to be installed in the global DNS." Some text to explain why would be helpful. |
2004-10-04
|
09 | Scott Hollenbeck | [Ballot Position Update] New position, Undefined, has been recorded for Scott Hollenbeck by Scott Hollenbeck |
2004-10-03
|
09 | Margaret Cullen | State Changes to IESG Evaluation from Waiting for Writeup::AD Followup by Margaret Wasserman |
2004-10-02
|
09 | Margaret Cullen | Placed on agenda for telechat - 2004-10-14 by Margaret Wasserman |
2004-10-02
|
09 | Margaret Cullen | [Ballot Position Update] New position, Yes, has been recorded for Margaret Wasserman |
2004-10-02
|
09 | Margaret Cullen | Ballot has been issued by Margaret Wasserman |
2004-10-02
|
09 | Margaret Cullen | Created "Approve" ballot |
2004-09-27
|
09 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2004-09-27
|
06 | (System) | New version available: draft-ietf-ipv6-unique-local-addr-06.txt |
2004-09-24
|
09 | Margaret Cullen | Sent reminder to authors about addressing IETF LC comments. |
2004-07-18
|
09 | Margaret Cullen | State Changes to Waiting for Writeup::Revised ID Needed from Waiting for Writeup by Margaret Wasserman |
2004-07-16
|
09 | (System) | State has been changed to Waiting for Writeup from In Last Call by system |
2004-07-01
|
09 | Amy Vezza | Last call sent |
2004-07-01
|
09 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Amy Vezza |
2004-06-30
|
09 | Margaret Cullen | Note field has been cleared by Margaret Wasserman |
2004-06-30
|
09 | Margaret Cullen | Last Call was requested by Margaret Wasserman |
2004-06-30
|
09 | Margaret Cullen | State Changes to Last Call Requested from AD Evaluation::AD Followup by Margaret Wasserman |
2004-06-30
|
09 | (System) | Ballot writeup text was added |
2004-06-30
|
09 | (System) | Last call text was added |
2004-06-30
|
09 | (System) | Ballot approval text was added |
2004-06-29
|
09 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2004-06-29
|
05 | (System) | New version available: draft-ietf-ipv6-unique-local-addr-05.txt |
2004-06-24
|
09 | Margaret Cullen | [Note]: 'Draft will be split into two separate drafts -- one with the randomly allocated addresses, and one with the registered addresses.' added by Margaret … [Note]: 'Draft will be split into two separate drafts -- one with the randomly allocated addresses, and one with the registered addresses.' added by Margaret Wasserman |
2004-06-24
|
09 | Margaret Cullen | State Changes to AD Evaluation::Revised ID Needed from AD Evaluation::AD Followup by Margaret Wasserman |
2004-05-25
|
09 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2004-05-25
|
04 | (System) | New version available: draft-ietf-ipv6-unique-local-addr-04.txt |
2004-03-14
|
09 | Margaret Cullen | Submission Questionnaire: 1) Have the chairs personally reviewed this version of the ID and do they believe this ID is sufficiently baked to forward … Submission Questionnaire: 1) Have the chairs personally reviewed this version of the ID and do they believe this ID is sufficiently baked to forward to the IESG for publication? Yes. 2) Has the document had adequate review from both key WG members and key non-WG members? Do you have any concerns about the depth or breadth of the reviews that have been performed? Review has been from many people in the IETF community, including Geoff Huston for the RIR community. We have no concerns about the reviews performed. 3) Do you have concerns that the document needs more review from a particular (broader) perspective (e.g., security, operational complexity, someone familiar with AAA, etc.)? We would expect more detailed discussion regarding the IANA considerations section instructing the IANA to set up an allocation authority for Unique Local IPv6 addresses. This shouldn't be a show stopper for advancing the document as the document carefully sets requirements and the IANA can setup the allocation authority as it sees fit. Note, that it is important to advance the document prior to this being settled as the document also allows for local assignment independent of a central assignment authority. 4) Do you have any specific concerns/issues with this document that you believe the ADs and/or IESG should be aware of? For example, perhaps you are uncomfortable with certain parts of the document, or whether there really is a need for it, etc., but at the same time these issues have been discussed in the WG and the WG has indicated it wishes to advance the document anyway. This document captures the consensus of the WG. 5) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The general topic area has been contentious for quite some time. However, we believe that this document does represent the consensus of the many and vocal members of the working group. It fills a need that many people have articulated on the mailing list and in working group meetings. 6) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize what are they upset about. This has been a contentious topic, but we are unaware of any planned appeal. 7) Have the chairs verified that the document adheres to _all_ of the ID nits? (see http://www.ietf.org/ID-nits.html). Yes. - Technical Summary This document defines an IPv6 unicast address format, called Unique Local IPv6 Unicast Addresses, that is globally unique and is intended for local communications. There are two ways to allocate these prefixes. These are centrally by a allocation authority and locally by the site. These addresses are intended to be the replacement for the Site-Local IPv6 addresses that are being deprecated. The ULA addresses offer a similar facility without the drawbacks associated with Site-Local unicast addresses. - Working Group Summary The IPv6 working group has done extensive review of this document and this document reflects the consensus of the group. - Protocol Quality This document has been reviewed by members of the ipv6@ietf.org mailing list and by the working group chairs. |
2004-03-14
|
09 | Margaret Cullen | State Changes to AD Evaluation::Revised ID Needed from AD Evaluation by Margaret Wasserman |
2004-03-14
|
09 | Margaret Cullen | Sent AD evaluation comments to IPv6 WG: SUBSTANTIVE ISSUES: (1) This draft doesn't mention the reverse DNS tree. Is it expected that whatever … Sent AD evaluation comments to IPv6 WG: SUBSTANTIVE ISSUES: (1) This draft doesn't mention the reverse DNS tree. Is it expected that whatever registry assigns these values will also populate the reverse DNS tree? Or not? (2) The document says: > Global IDs should be assigned centrally by a single allocation > authority because they are pseudo-random and without any structure. > This is easiest to accomplish if there is a single source for the > assignments. This would appear to be incompatible with the IANA considerations section that says: > If deemed > appropriate, the authority may also consist of multiple organizations > performing the authority duties. To avoid a situation where a single entity can request a large number of local prefixes and aggregate them, it isn't strictly necessary that the addresses be allocated from a single pool. If there were several pools (for different geographical regions, for example) random allocations from one of those pools would achieve the same result. (3) The document also says: > The requirements for centrally assigned global ID allocations are: > > - Available to anyone in an unbiased manner. > - Permanent with no periodic fees. It seems strange to say that there can be no periodic fees when the document doesn't mention fees anywhere else... Perhaps this is a leftover from previous versions of the document that did include a fee structure? > - Allocation on a permanent basis, without any need for renewal > and without any procedure for de-allocation. > - Provide mechanisms that prevent hoarding of these allocations. > - The ownership of each individual allocation should be private, > but should be escrowed. I am not sure that requiring a permanent escrow is consistent with the idea that there will be no ongoing revenue stream (i.e. periodic fees) associated with an address. (4) The algorithm for random number generation is: >3.2.3 Sample Code for Pseudo-Random Global ID Algorithm > > The algorithm described below is intended to be used for centrally > and locally assigned Global IDs. In each case the resulting global > ID will be used in the appropriate prefix as defined in section 3.2. > > 1) Obtain the current time of day in 64-bit NTP format [NTP]. > 2) Obtain an EUI-64 identifier from the system running this > algorithm. If an EUI-64 does not exist, one can be created from > a 48-bit MAC address as specified in [ADDARCH]. If an EUI-64 > cannot be obtained or created, a suitably unique identifier, > local to the node, should be used (e.g. system serial number). > 3) Concatenate the time of day with the system-specific identifier > creating a key. > 4) Compute an MD5 digest on the key as specified in [MD5DIG]. > 5) Use the least significant 40 bits as the Global ID. > > This algorithm will result in a global ID that is reasonably unique > and can be used as a Global ID. Are you intending that centrally assigned addresses will all be generated using the EUI-64 address of a server at the centralized registration authority? What affect would this have on the randomness of these allocations, and does that matter? EDITORIAL COMMENTS > - Allows sites to be combined or privately interconnected without > creating any address conflicts or require renumbering of > interfaces using these prefixes. s/require/requiring > Site border routers and firewalls should not forward any packets with > Local IPv6 source or destination addresses outside of the site unless > they have been explicitly configured with routing information about > other Local IPv6 prefixes. s/other// ?? >14.1 Normative References Did you really manage to get through this entire document without requiring any reference (normative or informative) to the Scoped Address Architecture? I seem to recall some mention of link-local addresses, for example. |
2004-02-22
|
09 | Margaret Cullen | State Changes to AD Evaluation from Publication Requested by Margaret Wasserman |
2004-02-19
|
09 | Dinara Suleymanova | Draft Added by Dinara Suleymanova |
2004-02-13
|
03 | (System) | New version available: draft-ietf-ipv6-unique-local-addr-03.txt |
2004-01-21
|
02 | (System) | New version available: draft-ietf-ipv6-unique-local-addr-02.txt |
2003-09-24
|
01 | (System) | New version available: draft-ietf-ipv6-unique-local-addr-01.txt |
2003-08-27
|
00 | (System) | New version available: draft-ietf-ipv6-unique-local-addr-00.txt |