IPv6 Unicast Address Assignment Considerations
RFC 5375
Revision differences
Document history
| Date | Rev. | By | Action |
|---|---|---|---|
|
2020-01-21
|
10 | (System) | Received changes through RFC Editor sync (added Verified Errata tag) |
|
2017-05-16
|
10 | (System) | Changed document authors from "Christian Hahn, Olaf Bonness, Gunter Van de Velde, Tim Chown" to "Christian Hahn, Olaf Bonness, Gunter Van de Velde, Tim Chown, … Changed document authors from "Christian Hahn, Olaf Bonness, Gunter Van de Velde, Tim Chown" to "Christian Hahn, Olaf Bonness, Gunter Van de Velde, Tim Chown, Chip Popoviciu" |
|
2015-10-14
|
10 | (System) | Notify list changed from v6ops-chairs@ietf.org, draft-ietf-v6ops-addcon@ietf.org to (None) |
|
2012-08-22
|
10 | (System) | post-migration administrative database adjustment to the No Objection position for Pasi Eronen |
|
2012-08-22
|
10 | (System) | post-migration administrative database adjustment to the Yes position for Jari Arkko |
|
2012-08-22
|
10 | (System) | post-migration administrative database adjustment to the No Objection position for Dan Romascanu |
|
2012-08-22
|
10 | (System) | post-migration administrative database adjustment to the Yes position for Mark Townsley |
|
2012-08-22
|
10 | (System) | post-migration administrative database adjustment to the No Objection position for Russ Housley |
|
2008-12-04
|
10 | Cindy Morgan | State Changes to RFC Published from RFC Ed Queue by Cindy Morgan |
|
2008-12-04
|
10 | Cindy Morgan | [Note]: 'RFC 5375' added by Cindy Morgan |
|
2008-12-03
|
10 | (System) | RFC published |
|
2008-10-09
|
10 | Cindy Morgan | State Changes to RFC Ed Queue from Approved-announcement sent by Cindy Morgan |
|
2008-10-09
|
10 | Cindy Morgan | IESG state changed to Approved-announcement sent |
|
2008-10-09
|
10 | Cindy Morgan | IESG has approved the document |
|
2008-10-09
|
10 | Cindy Morgan | Closed "Approve" ballot |
|
2008-10-09
|
10 | Ron Bonica | State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Ron Bonica |
|
2008-10-08
|
10 | Pasi Eronen | [Ballot Position Update] Position for Pasi Eronen has been changed to No Objection from Discuss by Pasi Eronen |
|
2008-09-22
|
10 | Pasi Eronen | [Ballot comment] Version -10 has couple of editorial nits, which probably should be fixed before sending this to the RFC editor: Sections 4..8 got renumbered … [Ballot comment] Version -10 has couple of editorial nits, which probably should be fixed before sending this to the RFC editor: Sections 4..8 got renumbered to 3.2..3.5 -- a misplaced </section> tag, perhaps? And in Section B.2.1, "earlier in this section" should be "later in this section". |
|
2008-09-22
|
10 | Pasi Eronen | [Ballot discuss] The text in version -10 is acceptable to me, but since it's not fully aligned with the IPv6 Addressing Architecture (or perhaps the … [Ballot discuss] The text in version -10 is acceptable to me, but since it's not fully aligned with the IPv6 Addressing Architecture (or perhaps the addressing architecture isn't fully aligned with the reality), at least 6MAN WG needs to review it (since this document didn't go through IETF Last Call). I'll clear my DISCUSS once 6MAN WG has been given a week to review it, and Jari's happy with their response. |
|
2008-09-22
|
10 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
|
2008-09-22
|
10 | (System) | New version available: draft-ietf-v6ops-addcon-10.txt |
|
2008-09-22
|
10 | Jari Arkko | [Ballot Position Update] Position for Jari Arkko has been changed to Yes from Discuss by Jari Arkko |
|
2008-09-11
|
10 | Ron Bonica | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation::AD Followup by Ron Bonica |
|
2008-09-10
|
10 | Mark Townsley | [Ballot Position Update] Position for Mark Townsley has been changed to Yes from Discuss by Mark Townsley |
|
2008-08-08
|
10 | Pasi Eronen | [Ballot discuss] Section 2 says that this document considers global addresses (assigned from RIR/LIR) and ULAs -- neither of which starts with binary 000, right? … [Ballot discuss] Section 2 says that this document considers global addresses (assigned from RIR/LIR) and ULAs -- neither of which starts with binary 000, right? Given this, I'm having trouble understanding why Sections 3.1 and 3.3 exist. I've certainly heard rumors that some folks would like change the RFC 4291 requirement changed (and use other subnet prefix lengths even with addresses that don't start with binary 000), or would like to ignore the requirement. I have not followed this topic recently, though -- is there ongoing work about this? (Nevertheless, it seems updating RFC 4291 isn't within the scope of this document.) |
|
2008-08-08
|
09 | (System) | New version available: draft-ietf-v6ops-addcon-09.txt |
|
2008-06-13
|
10 | Dan Romascanu | [Ballot Position Update] Position for Dan Romascanu has been changed to No Objection from Discuss by Dan Romascanu |
|
2008-06-04
|
10 | Russ Housley | [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss by Russ Housley |
|
2008-06-04
|
10 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
|
2008-06-04
|
08 | (System) | New version available: draft-ietf-v6ops-addcon-08.txt |
|
2008-05-22
|
10 | Cindy Morgan | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Cindy Morgan |
|
2008-05-22
|
10 | Magnus Westerlund | [Ballot Position Update] New position, No Objection, has been recorded by Magnus Westerlund |
|
2008-05-22
|
10 | Ross Callon | [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon |
|
2008-05-22
|
10 | Jari Arkko | [Ballot discuss] I think this is a useful document and with two small corrections I will move to a Yes position: > Using a random … [Ballot discuss] I think this is a useful document and with two small corrections I will move to a Yes position: > Using a random chosen ULA address will be conform in case > (a) provide suboptimal aggregation capability, while in case (c) > there will be overconsumption of address space. First, I cannot parse this sentence. Second, if the intention was to say that in some cases ULAs are consuming too much address space, I do not agree. The amount of space given for ULA addresses is fixed, and independent of the use of ULAs. Section 2.4. explains the issues with ULAs quite well. I wonder if the above sentence could simply be deleted. Section 3.2 says: Note that RFC3177 strongly prescribes 64 bit subnets for general usage, and that stateless autoconfiguration option is only defined for 64 bit subnets. However, implementations could use proprietary mechanism for stateless autoconfiguration for different then 64 bit prefix length. I am against the IETF making the recommendation in the last sentence. What proprietary mechanisms? Not supported on the system I am writing this text on... And then Section 3.3 goes on to explain the >64 bits prefix case. I would like the last sentence from Section 3.2 removed, and Section 3.3 edited to make a stronger recommendation against using >64 bit prefixes. In particular, that section needs to indicate that ND, privacy, SEND, etc. all stop working with such prefixes. Note that I am not advocating outlawing such prefixes; I would still allow them, e.g., for p2p links in some cases. Even if I would personally still use a /64 even for them. But I digress. |
|
2008-05-22
|
10 | Jari Arkko | [Ballot comment] The document says: However multihoming also has some operative and administrative burdens besides chosing multiple addresses per interface [33] [25][24]. … [Ballot comment] The document says: However multihoming also has some operative and administrative burdens besides chosing multiple addresses per interface [33] [25][24]. I'm not sure these references are adequate. It would be good to point to the recent v6ops document that described issues with address selection, for instance. Also, I wonder if pointing to Shim6 documents as Informative references would be useful as well. References to RFC 3041 should be replaced by references to 4941. |
|
2008-05-22
|
10 | Jari Arkko | [Ballot discuss] > Using a random chosen ULA address will be conform in case > (a) provide suboptimal aggregation capability, while in case (c) > … [Ballot discuss] > Using a random chosen ULA address will be conform in case > (a) provide suboptimal aggregation capability, while in case (c) > there will be overconsumption of address space. First, I cannot parse this sentence. Second, if the intention was to say that in some cases ULAs are consuming too much address space, I do not agree. The amount of space given for ULA addresses is fixed, and independent of the use of ULAs. Section 2.4. explains the issues with ULAs quite well. I wonder if the above sentence could simply be deleted. |
|
2008-05-22
|
10 | Jari Arkko | [Ballot discuss] > Using a random chosen ULA address will be conform in case > (a) provide suboptimal aggregation capability, while in case (c) > … [Ballot discuss] > Using a random chosen ULA address will be conform in case > (a) provide suboptimal aggregation capability, while in case (c) > there will be overconsumption of address space. First, I cannot parse this sentence. Second, if the intention was to say that in some cases ULAs are consuming too much address space, I do not agree. The amount of space given for ULA addresses is fixed, and independent of the use of ULAs. |
|
2008-05-22
|
10 | Jari Arkko | [Ballot Position Update] New position, Discuss, has been recorded by Jari Arkko |
|
2008-05-22
|
10 | Jari Arkko | [Ballot comment] The document says: However multihoming also has some operative and administrative burdens besides chosing multiple addresses per interface [33] [25][24]. … [Ballot comment] The document says: However multihoming also has some operative and administrative burdens besides chosing multiple addresses per interface [33] [25][24]. I'm not sure these references are adequate. It would be good to point to the recent v6ops document that described issues with address selection, for instance. Also, I wonder if pointing to Shim6 documents as Informative references would be useful as well. |
|
2008-05-22
|
10 | Pasi Eronen | [Ballot discuss] Section 2 says that this document considers global addresses (assigned from RIR/LIR) and ULAs -- neither of which starts with binary 000, right? … [Ballot discuss] Section 2 says that this document considers global addresses (assigned from RIR/LIR) and ULAs -- neither of which starts with binary 000, right? Given this, I'm having trouble understanding why Sections 3.1 and 3.3 exist. I've certainly heard rumors that some folks would like change the RFC 4291 requirement changed (and use other subnet prefix lengths even with addresses that don't start with binary 000), or would like to ignore the requirement. I have not followed this topic recently, though -- is there ongoing work about this? (Nevertheless, it seems updating RFC 4291 isn't within the scope of this document.) Section 6 should say that using subnet prefixes other than /64 breaks security mechanisms such as Cryptographically Generated Addresses (CGAs) and Hash Based Addresses (HBAs), and thus makes it impossible to use protocols that depend on them. |
|
2008-05-22
|
10 | Pasi Eronen | [Ballot Position Update] New position, Discuss, has been recorded by Pasi Eronen |
|
2008-05-22
|
10 | Chris Newman | [Ballot Position Update] New position, No Objection, has been recorded by Chris Newman |
|
2008-05-21
|
10 | Dan Romascanu | [Ballot comment] 1. Please expand RIR and LIR at first occurence 2. The 'we' language in subsection of Annex A1 seems unappropriate 3. The 'requirements' … [Ballot comment] 1. Please expand RIR and LIR at first occurence 2. The 'we' language in subsection of Annex A1 seems unappropriate 3. The 'requirements' language in subsections A2.1.1, A2.1.2, A2.1.3 seems unappropriate. This being an Informational RFC and the ennexes describing operational experience in specific deployments it seems right to talk about 'recommendations' rather than 'requirements;. |
|
2008-05-21
|
10 | Dan Romascanu | [Ballot discuss] The WG summary needs some editing aas this will be part of the announcement - right now it just says 'not really' |
|
2008-05-21
|
10 | Dan Romascanu | [Ballot discuss] The WG sumary needs some editing aas this will be part of the announcement - right now it just says 'not really' |
|
2008-05-21
|
10 | Dan Romascanu | [Ballot Position Update] New position, Discuss, has been recorded by Dan Romascanu |
|
2008-05-20
|
10 | Lars Eggert | [Ballot Position Update] New position, No Objection, has been recorded by Lars Eggert |
|
2008-05-20
|
10 | (System) | State Changes to IESG Evaluation from IESG Evaluation - Defer by system |
|
2008-05-15
|
10 | Mark Townsley | [Ballot discuss] > 3.1. Considerations for subnet prefixes shorter then /64 > > An allocation of a prefix shorter then 64 bits to a … [Ballot discuss] > 3.1. Considerations for subnet prefixes shorter then /64 > > An allocation of a prefix shorter then 64 bits to a node or interface > is considered bad practice. One exception to this statement is when > using 6to4 technology where a /16 prefix is utilised for the pseudo- > interface [8]. The shortest subnet prefix that could theoretically > be assigned to an interface or node is limited by the size of the > network prefix allocated to the organization. > > A possible reason for choosing the subnet prefix for an interface > shorter then /64 is that it would allow more nodes to be attached to > that interface compared to a prescribed length of 64 bits. This > however is unnecessary for most networks considering that 2^64 > provides plenty of node addresses. > > The subnet prefix assignments can be made either by manual > configuration, by a stateful Host Configuration Protocol [11], by a > stateful prefix delegation mechanism [16] or implied by stateless > autoconfiguration from prefix RAs. I think that another possible reason for choosing a subnet prefix for an interface shorter than 64 is to enable routing among interfaces connected to a device which is only able to obtain a /64. For example, a residential gateway which receives a /64 (and has no other option, or other options cost money), is situated in a home with multiple LANs of different media types (sensor network, wired, wifi, etc.), or has a need for traffic segmentation (home, work, kids, etc.) could benefit greatly from multiple subnets and routing in IPv6. Ideally, residential networks would be given an address range larger than /64 (e.g., via DHCP-PD) such that multiple /64 subnets could be used within the residence. However, if that is not the case, one might be tempted to segment the /64, or worse, NAT it. I think that it would be a good idea to point this out, as well as to provide some advice to SPs who provide residential access to consider always assigning a prefix shorter than /64 to homes so that subnetting and routing can be handled properly from the start. I am afraid that the alternative is that home networking equipment could end up evolving in a way that does not route properly, or at all (NAT, L2 interworking, etc). I would go so far as to say that /56 is the ideal balance between /48 and /64 for a typical residential home gateway (i.e., "small site"). This is consistent with APNIC and ARIN who have adopted a /56 recommendation for "small sites" - something that probably should be pointed out as well. Nits: > In all above cases the ULA > addresses can be randomly chosen according the principles specified > in [19]. [19] (RFC 3879) doesn't describe how to choose a ULA, RFC 4193 does. > Most implementations know about Site-local addresses even > though they are deprecated, and do not know about ULAs - even though > they represent current specification. As result transitioning > between these types of addresses may cause difficulties. At the time of this document's writing, most implementations... > Using a random chosen ULA address will be conform in case > (a) provide suboptimal aggregation capability, while in case (c) > there will be overconsumption of address space. Sentence doesn't parse. |
|
2008-05-15
|
10 | Mark Townsley | [Ballot Position Update] New position, Discuss, has been recorded by Mark Townsley |
|
2008-05-09
|
10 | (System) | Removed from agenda for telechat - 2008-05-08 |
|
2008-05-08
|
10 | Samuel Weiler | Request for Telechat review by SECDIR Completed. Reviewer: Sean Turner. |
|
2008-05-07
|
10 | David Ward | [Ballot Position Update] New position, No Objection, has been recorded by David Ward |
|
2008-05-07
|
10 | Mark Townsley | State Changes to IESG Evaluation - Defer from IESG Evaluation by Mark Townsley |
|
2008-05-07
|
10 | Tim Polk | [Ballot comment] There are a number of useful suggestions and editorial corrections in Elwyn Davies' GenArt Review. Since this review was posted on May 6, … [Ballot comment] There are a number of useful suggestions and editorial corrections in Elwyn Davies' GenArt Review. Since this review was posted on May 6, I wanted to call it to the authors and wg chairs attention. There are three specific issues I found especially compelling: s1, bullet 3 (near end): s/traffic storm and level/potential traffic storms and the level/ No further mention of traffic storms is made in the document... should it be to give some hints on subnet sizing? s2.2, para3: 'Using a random chosen ULA address will be conform in case (a) provide suboptimal aggregation capability, while in case (c) there will be overconsumption of address space.' This sentence is not good English and I don't understand what it is trying to say regarding case (a). s3.3, para 3: It would be useful to explain why the u and g bits might come back to bite us in future or provide a reference which discusses why they are relevant at all. While I am most anxious to resolve the three issues above, all the changes Elwyn proposed appear well founded to me. The full review is available at http://www.ietf.org/mail-archive/web/gen-art/current/msg02970.html |
|
2008-05-07
|
10 | Tim Polk | [Ballot comment] There are a number of useful suggestions and editorial corrections in Elwyn Davies' GenArt Review. Since this review was posted on May 6, … [Ballot comment] There are a number of useful suggestions and editorial corrections in Elwyn Davies' GenArt Review. Since this review was posted on May 6, I wanted to call it to the authors and wg chairs attention. There are three specific issues I found especially compelling: s1, bullet 3 (near end): s/traffic storm and level/potential traffic storms and the level/ No further mention of traffic storms is made in the document... should it be to give some hints on subnet sizing? s2.2, para3: 'Using a random chosen ULA address will be conform in case (a) provide suboptimal aggregation capability, while in case (c) there will be overconsumption of address space.' This sentence is not good English and I don't understand what it is trying to say regarding case (a). s3.3, para 3: It would be useful to explain why the u and g bits might come back to bite us in future or provide a reference which discusses why they are relevant at all. While I am most anxious to resolve the three issues above, all the changes Elwyn proposed appear well founded to me. The full review is available at http://www.ietf.org/mail-archive/web/gen-art/current/msg02970.html |
|
2008-05-07
|
10 | Tim Polk | [Ballot Position Update] New position, No Objection, has been recorded by Tim Polk |
|
2008-05-06
|
10 | Cullen Jennings | [Ballot Position Update] New position, No Objection, has been recorded by Cullen Jennings |
|
2008-05-06
|
10 | Russ Housley | [Ballot discuss] Some changes were agreed based on the comments in the SecDir Review by Sean Turner. However, there are not any RFC Editor … [Ballot discuss] Some changes were agreed based on the comments in the SecDir Review by Sean Turner. However, there are not any RFC Editor notes or an updated version since that discussion. |
|
2008-05-06
|
10 | Russ Housley | [Ballot Position Update] New position, Discuss, has been recorded by Russ Housley |
|
2008-05-06
|
10 | Lisa Dusseault | [Ballot comment] This comment is only a bunch of nits, I liked the doc itself Section 1. Reference [32] is to an expired draft -- … [Ballot comment] This comment is only a bunch of nits, I liked the doc itself Section 1. Reference [32] is to an expired draft -- draft-chown-v6ops-renumber-thinkabout. I hope the authors revive this (and as an aside, if you do, I hope to better understand the overlap with RFC4192) Section 2.1: Reference [33] is too broad and unstable. Aren't references [25] and [24] enough here? Section 2.2: RPF should be expanded (Reverse Path Forwarding) Section 2.3: RIR should be expanded (Regional Internet Registries?) Section 2.4: However, there is no rule to disallow large networks to use a single ULA for all 'sites' I believe this should be However, there is no rule to disallow large networks to use a single ULA prefix for all 'sites' Section 2.4.2: HD should be expanded, I mention this for completeness because the reference right there makes this one easy to track down. to get really nitpicky, the reference itself is wrong tho, should be "Host-Density" instead of "H-Density". Section 3.3.1.1: last sentence doesn't parse to me... |
|
2008-05-06
|
10 | Lisa Dusseault | [Ballot comment] Section 1. Reference [32] is to an expired draft -- draft-chown-v6ops-renumber-thinkabout. I hope the authors revive this (and as an aside, if you … [Ballot comment] Section 1. Reference [32] is to an expired draft -- draft-chown-v6ops-renumber-thinkabout. I hope the authors revive this (and as an aside, if you do, I hope to better understand the overlap with RFC4192) Section 2.1: Reference [33] is too broad and unstable. Aren't references [25] and [24] enough here? Section 2.2: RPF should be expanded (Reverse Path Forwarding) Section 2.3: RIR should be expanded (Regional Internet Registries?) Section 2.4: However, there is no rule to disallow large networks to use a single ULA for all 'sites' I believe this should be However, there is no rule to disallow large networks to use a single ULA prefix for all 'sites' Section 2.4.2: HD should be expanded, I mention this for completeness because the reference right there makes this one easy to track down. to get really nitpicky, the reference itself is wrong tho, should be "Host-Density" instead of "H-Density". Section 3.3.1.1: last sentence doesn't parse to me... |
|
2008-05-06
|
10 | Lisa Dusseault | [Ballot Position Update] New position, Yes, has been recorded by Lisa Dusseault |
|
2008-05-05
|
10 | Amanda Baber | IANA Evaluation comments: We understand that this document does not request any IANA actions. |
|
2008-05-02
|
10 | Samuel Weiler | Request for Telechat review by SECDIR is assigned to Sean Turner |
|
2008-05-02
|
10 | Samuel Weiler | Request for Telechat review by SECDIR is assigned to Sean Turner |
|
2008-04-29
|
10 | Ron Bonica | Placed on agenda for telechat - 2008-05-08 by Ron Bonica |
|
2008-04-29
|
10 | Ron Bonica | [Ballot Position Update] New position, Yes, has been recorded for Ronald Bonica |
|
2008-04-29
|
10 | Ron Bonica | Ballot has been issued by Ron Bonica |
|
2008-04-29
|
10 | Ron Bonica | Created "Approve" ballot |
|
2008-04-29
|
10 | (System) | Ballot writeup text was added |
|
2008-04-29
|
10 | (System) | Last call text was added |
|
2008-04-29
|
10 | (System) | Ballot approval text was added |
|
2008-04-29
|
10 | Ron Bonica | State Changes to IESG Evaluation from Publication Requested by Ron Bonica |
|
2008-01-21
|
10 | Dinara Suleymanova | PROTO Write-up >> (1.a) Who is the Document Shepherd for this document? > > Fred Baker > >> Has the Document Shepherd personally reviewed this … PROTO Write-up >> (1.a) Who is the Document Shepherd for this document? > > Fred Baker > >> Has the Document Shepherd personally reviewed this version of the >> document and, in particular, does he or she believe this version >> is ready for forwarding to the IESG for publication? > > Yes I do. > >> (1.b) Has the document had adequate review both from key WG >> members and from key non-WG members? Does the Document Shepherd >> have any concerns about the depth or breadth of the reviews that >> have been performed? > > Yes, it has. This document grew out of discussions among various > networks along with Cisco as a vendor, and addressing issues that > they each had. This has been presented to the working group twice, > each time with some discussion but few consensus problems. The > operational recommendations it makes are in no sense exhaustive, > but they do represent practices that have been proven in the field. > One could argue that it should be BCP, and probably should be taken > to that status at some future time. > >> (1.c) Does the Document Shepherd have concerns that the document >> needs more review from a particular or broader perspective, e.g., >> security, operational complexity, someone familiar with AAA, >> internationalization or XML? > > It has had operational review, being largely written and commented > on by operators. It doesn't especially bring up the other issues > asked about here, and so does not require their review beyond > assuring themselves that this is the case. > >> (1.d) Does the Document Shepherd have any specific concerns or >> issues with this document that the Responsible Area Director and/ >> or the IESG should be aware of? For example, perhaps he or she is >> uncomfortable with certain parts of the document, or has concerns >> whether there really is a need for it. In any event, if the WG has >> discussed those issues and has indicated that it still wishes to >> advance the document, detail those concerns here. Has an IPR >> disclosure related to this document been filed? If so, please >> include a reference to the disclosure and summarize the WG >> discussion and conclusion on this issue. > > No. > >> (1.e) 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? > > Working Group consensus is fairly strong behind the document, as > demonstrated in the working group discussions. There is not a lot > of list discussion, but there has been good discussion and solid > support in face-to-face meetings. > >> (1.f) Has anyone threatened an appeal or otherwise indicated >> extreme discontent? If so, please summarise the areas of conflict >> in separate email messages to the Responsible Area Director. (It >> should be in a separate email because this questionnaire is >> entered into the ID Tracker.) > > no. > >> (1.g) Has the Document Shepherd personally verified that the >> document satisfies all ID nits? > > Yes. > > The idnits tool notes a bit of text that looks like a reference but > is not, and three referenced documents were obsoleted by new RFCs > in September. I believe that the RFC Editor can address the three > references if instructed to in a note, but if there are other > updates required the authors could pick up the references when > doing so. > >> (See http://www.ietf.org/ID-Checklist.html and http:// >> tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; >> this check needs to be thorough. Has the document met all formal >> review criteria it needs to, such as the MIB Doctor, media type >> and URI type reviews? > > >> (1.h) Has the document split its references into normative and >> informative? > > Yes > >> Are there normative references to documents that are not ready for >> advancement or are otherwise in an unclear state? If such >> normative references exist, what is the strategy for their >> completion? Are there normative references that are downward >> references, as described in [RFC3967]? If so, list these downward >> references to support the Area Director in the Last Call procedure >> for them [RFC3967]. > > no. > >> (1.i) Has the Document Shepherd verified that the document IANA >> consideration section exists and is consistent with the body of >> the document? If the document specifies protocol extensions, are >> reservations requested in appropriate IANA registries? Are the >> IANA registries clearly identified? If the document creates a new >> registry, does it define the proposed initial contents of the >> registry and an allocation procedure for future registrations? >> Does it suggest a reasonable name for the new registry? See >> [RFC2434]. If the document describes an Expert Review process has >> Shepherd conferred with the Responsible Area Director so that the >> IESG can appoint the needed Expert during the IESG Evaluation? > > There are no extra IANA consideration for this document, and the > document states as much. > >> (1.j) Has the Document Shepherd verified that sections of the >> document that are written in a formal language, such as XML code, >> BNF rules, MIB definitions, etc., validate correctly in an >> automated checker? > > there is no formal language of this type in the document. > >> (1.k) The IESG approval announcement includes a Document >> Announcement Write-Up. Please provide such a Document Announcement >> Write-Up? Recent examples can be found in the "Action" >> announcements for approved documents. The approval announcement >> contains the following sections: > >> Technical Summary: Relevant content can frequently be found in the >> abstract and/or introduction of the document. If not, this may be >> an indication that there are deficiencies in the abstract or >> introduction. > > the abstract reads: > > One fundamental aspect of any IP communications infrastructure > is its > addressing plan. With its new address architecture and allocation > policies, the introduction of IPv6 into a network means that > network > designers and operators need to reconsider their existing > approaches > to network addressing. Lack of guidelines on handling this > aspect of > network design could slow down the deployment and integration of > IPv6. This document aims to provide the information and > recommendations relevant to planning the addressing aspects of IPv6 > deployments. The document also provides IPv6 addressing case > studies > for both an enterprise and an ISP network. > >> Working Group Summary: Was there anything in WG process that is >> worth noting? For example, was there controversy about particular >> points or were there decisions where the consensus was >> particularly rough? > > not really. > >> Document Quality: Are there existing implementations of the >> protocol? Have a significant number of vendors indicated their >> plan to implement the specification? Are there any reviewers that >> merit special mention as having done a thorough review, e.g., one >> that resulted in important changes or a conclusion that the >> document had no substantive issues? If there was a MIB Doctor, >> Media Type or other expert review, what was its course (briefly)? >> In the case of a Media Type review, on what date was the request >> posted? > > > This is not a protocol. However, its recommendations are indeed > widely implemented; it documents practice. > > > idnits 2.05.02 > > tmp/draft-ietf-v6ops-addcon-07.txt: > tmp/draft-ietf-v6ops-addcon-07.txt(932): Appendix start: Appendix > A. Case Studies. > - Failure fetching the file, proceeding without it.) > Appendix start: Appendix A. Case Studies > > Checking boilerplate required by RFC 3978 and 3979, updated by > RFC 4748: > - > ---------------------------------------------------------------------- > --- ---- > > No issues found here. > > Checking nits according to http://www.ietf.org/ietf/1id- > guidelines.txt: > - > ---------------------------------------------------------------------- > --- ---- > > No issues found here. > > Checking nits according to http://www.ietf.org/ID-Checklist.html: > - > ---------------------------------------------------------------------- > --- ---- > > No issues found here. > > Miscellaneous warnings: > - > ---------------------------------------------------------------------- > --- ---- > > No issues found here. > > Checking references for intended status: Informational > - > ---------------------------------------------------------------------- > --- ---- > > -- Looks like a reference, but probably isn't: 'RIID' on line 496 > 'Where: [RIID] = 4 bit....' > > -- Obsolete informational reference (is this intentional?): RFC > 2462 (ref. > '2') (Obsoleted by RFC 4862) > > -- Obsolete informational reference (is this intentional?): RFC > 2471 (ref. > '3') (Obsoleted by RFC 3701) > > -- Obsolete informational reference (is this intentional?): RFC > 3041 (ref. > '6') (Obsoleted by RFC 4941) > > == Outdated reference: A later version (-04) exists of > draft-ietf-v6ops-scanning-implications-03 > > > Summary: 0 errors (**), 1 warning (==), 4 comments (--). > - |
|
2008-01-21
|
10 | Dinara Suleymanova | Draft Added by Dinara Suleymanova in state Publication Requested |
|
2007-11-07
|
07 | (System) | New version available: draft-ietf-v6ops-addcon-07.txt |
|
2007-10-01
|
06 | (System) | New version available: draft-ietf-v6ops-addcon-06.txt |
|
2007-06-29
|
05 | (System) | New version available: draft-ietf-v6ops-addcon-05.txt |
|
2007-06-21
|
04 | (System) | New version available: draft-ietf-v6ops-addcon-04.txt |
|
2007-03-05
|
03 | (System) | New version available: draft-ietf-v6ops-addcon-03.txt |
|
2006-10-26
|
02 | (System) | New version available: draft-ietf-v6ops-addcon-02.txt |
|
2006-07-11
|
01 | (System) | New version available: draft-ietf-v6ops-addcon-01.txt |
|
2006-06-02
|
00 | (System) | New version available: draft-ietf-v6ops-addcon-00.txt |