Basic Requirements for IPv6 Customer Edge Routers
draft-ietf-v6ops-6204bis-12
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2013-11-22
|
12 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2013-11-21
|
12 | (System) | RFC Editor state changed to AUTH48 from AUTH48-DONE |
2013-11-21
|
12 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2013-11-17
|
12 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2013-11-11
|
12 | (System) | RFC Editor state changed to RFC-EDITOR from REF |
2013-10-16
|
12 | (System) | RFC Editor state changed to REF from RFC-EDITOR |
2013-10-15
|
12 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2013-10-01
|
12 | Fred Baker | Changed consensus to Yes from Unknown |
2013-10-01
|
12 | Fred Baker | Document shepherd changed to Fred Baker |
2013-09-30
|
12 | (System) | RFC Editor state changed to EDIT from MISSREF |
2012-11-02
|
12 | Amy Vezza | State changed to RFC Ed Queue from Approved-announcement sent |
2012-11-01
|
12 | (System) | IANA Action state changed to No IC |
2012-11-01
|
12 | Amy Vezza | State changed to Approved-announcement sent from Approved-announcement to be sent |
2012-11-01
|
12 | Amy Vezza | IESG has approved the document |
2012-11-01
|
12 | Amy Vezza | Closed "Approve" ballot |
2012-11-01
|
12 | Amy Vezza | Ballot approval text was generated |
2012-11-01
|
12 | Amy Vezza | Ballot writeup was changed |
2012-11-01
|
12 | Ron Bonica | State changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2012-10-30
|
12 | Ralph Droms | [Ballot comment] I've cleared my Discuss; thanks for addressing all of my Discuss points. 1. (cleared) 2. (cleared) 3. (cleared) 4. (cleared) 5. (cleared) |
2012-10-30
|
12 | Ralph Droms | [Ballot Position Update] Position for Ralph Droms has been changed to No Objection from Discuss |
2012-10-30
|
12 | Cindy Morgan | New version available: draft-ietf-v6ops-6204bis-12.txt |
2012-10-29
|
11 | Sean Turner | [Ballot comment] Apologies for the delay. |
2012-10-29
|
11 | Sean Turner | [Ballot Position Update] Position for Sean Turner has been changed to No Objection from Discuss |
2012-10-23
|
11 | Ralph Droms | [Ballot comment] 1. (cleared) 2. (cleared) 3. (cleared) 4. (cleared) 5. (cleared) |
2012-10-23
|
11 | Ralph Droms | Ballot comment text updated for Ralph Droms |
2012-10-19
|
11 | Ralph Droms | [Ballot discuss] 1. (resolved) 2. (resolved) 3. Is it the intention of this document to preclude the use of DHCPv6 PD if neither the M … [Ballot discuss] 1. (resolved) 2. (resolved) 3. Is it the intention of this document to preclude the use of DHCPv6 PD if neither the M or O bit are set in a received router advertisement? (2012-10-19) More specifically, referencing WPD-4, what is the behavior of the CE router in the case where neither bit is set in a received RA? 4. I know I read and approved WPD-5 in RFC 6204. I think I know the intent of WPD-5, but now I'm not sure that the words actually match the intent. I'd like to discuss the intent to make sure I have it right, and then discuss the specific words to agree that they accurately convey that intent. (2012-10-19) Now I understand the intent: black-hole packets that have a destination address in the delegated prefix but are not in any prefix assigned out of the delegated prefix by the CE router. Can you rewrite WPD-5 to be more clear? Perhaps: WPD-5: Any packet received by the CE router with a destination address in the prefix(es) delegated to the CE router but not in the set of prefixes assigned by the CE router to the LAN must be dropped. In other words, the next hop for the prefix(es) delegated to the CE router should be the null destination. This is necessary to prevent forwarding loops when some addresses covered by the aggregate are not reachable [RFC4632]. (a) The IPv6 CE router SHOULD send an ICMPv6 Destination Unreachable message in accordance with Section 3.1 of [RFC4443] back to the source of the packet, if the packet is to be dropped due to this rule. 5. (cleared) 6. How is the use of 6rd and DS-lite controlled -specifically enabled and disabled? (2012-10-19) For example, does requirement 6RD-1 imply that the CE router is assumed to run 6rd with no mechanism for disabling it? |
2012-10-19
|
11 | Ralph Droms | [Ballot comment] 1. (cleared) 2. (cleared) 3. (cleared) 4. There are several requirements in the text that are not explicitly labeled as such; e.g., from … [Ballot comment] 1. (cleared) 2. (cleared) 3. (cleared) 4. There are several requirements in the text that are not explicitly labeled as such; e.g., from section 4.4.2: The IPv6 CE Router SHOULD implement DS-Lite functionality. Is there a reason for the inconsistency? (2012-10-19) Specifically, why is this requirement (and other sentences using RFC 2119 language but not in a labeled requirement) not a labeled requirement? 5. (cleared) |
2012-10-19
|
11 | Ralph Droms | Ballot comment and discuss text updated for Ralph Droms |
2012-10-10
|
11 | Pete Resnick | [Ballot comment] I have moved to "Abstain" on this document since I really don't think that further discussion is going to be fruitful. If the … [Ballot comment] I have moved to "Abstain" on this document since I really don't think that further discussion is going to be fruitful. If the WG is willing to make the following changes, great. If not, I'm not really willing to argue about it; this is, after all, an update to a document that does almost the same thing. I simply disagree with claiming that the keywords "are to be interpreted as described in RFC 2119"; they are not being used as 2119 intended, but rather to be industry cudgels as part of protocol policing. So, here are my two suggested changes: Change the first paragraph of section 1 to: This document defines basic IPv6 features for a residential or small- office router, referred to as an IPv6 CE router, in order to establish an industry baseline for features to be implemented on such a router. These routers typically also support IPv4. And in section 1.1: Take careful note: Unlike other IETF documents, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are not used as described in RFC 2119 [RFC2119]. This document uses these keyword not strictly for the purpose of interoperability, but rather for the purpose of establishing industry-common baseline functionality. As such, the document points to several other specifications (preferable in RFC or stable form) to provide additional guidance to implementers regarding any protocol implementation required to produce a successful CPE router that interoperates successfully with a particular subset of currently deploying and planned common IPv6 access networks. 3.1: I think it should be made clearer (either by separating it out or by signposting it a bit better) that this section is more about the current state of deployment than it is about the desired architecture. It caused me a bit of confusion, thinking that this was talking about what was desired, not simply what is. |
2012-10-10
|
11 | Pete Resnick | [Ballot Position Update] Position for Pete Resnick has been changed to Abstain from Discuss |
2012-09-25
|
11 | Brian Haberman | [Ballot Position Update] Position for Brian Haberman has been changed to No Objection from Discuss |
2012-09-25
|
11 | Brian Haberman | [Ballot discuss] I have no problems with the publication of this document, but I do have one remaining issue that I would like to see … [Ballot discuss] I have no problems with the publication of this document, but I do have one remaining issue that I would like to see discussed. 1. Fixed in -11 Given that this document is really meant to reflect what external organizations are requesting/specifying for their CE devices, I am clearing my DISCUSS points 2 (PCP), 3 (NTP), and 5 (downgraded requirement). 4. Section 4.4 discusses the requirements for transition technologies. However, it is unclear as to why 6rd and DS-Lite are the only two mentioned. I would like to see some introductory discussion as to why those two were chosen and others were not. This does not need to be normative, just a brief outline of how the choices came to be. Additionally, the discussion of transition technology lists both 6rd and DS-Lite as SHOULD implement. Is a CE compliant with this spec if it does not provide any transition technologies? Is it compliant if it provides only 6to4? |
2012-09-25
|
11 | Brian Haberman | Ballot comment and discuss text updated for Brian Haberman |
2012-09-25
|
11 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2012-09-25
|
11 | Hemant Singh | New version available: draft-ietf-v6ops-6204bis-11.txt |
2012-09-25
|
10 | Brian Haberman | [Ballot discuss] I have no problems with the publication of this document, but I do have some issues that I would like to see discussed. … [Ballot discuss] I have no problems with the publication of this document, but I do have some issues that I would like to see discussed. 1. RFC 6204 lists Ole Troan as the editor, but this draft does not have his name listed anywhere (author, editor, or contributor). Why is that? Given that this document is really meant to reflect what external organizations are requesting/specifying for their CPE devices, I am clearing my DISCUSS points 2 (PCP), 3 (NTP), and 5 (downgraded requirement). 4. Section 4.4 discusses the requirements for transition technologies. However, it is unclear as to why 6rd and DS-Lite are the only two mentioned. I would like to see some introductory discussion as to why those two were chosen and others were not. This does not need to be normative, just a brief outline of how the choices came to be. |
2012-09-25
|
10 | Brian Haberman | Ballot discuss text updated for Brian Haberman |
2012-08-23
|
10 | Pete Resnick | [Ballot discuss] [Updating given replies from the authors/shepherd] If this document is truly our current best thinking about how to build an IPv6 CE box … [Ballot discuss] [Updating given replies from the authors/shepherd] If this document is truly our current best thinking about how to build an IPv6 CE box in order for it to interoperate well with other network components, I would prefer to see this document as a Standards Track document. It "identifies the relevant technical specifications (TSs) and the specific way in which they are to be combined", it specifies "particular values or ranges of TS parameters or subfunctions of a TS protocol that must be implemented", and it specifies "particular methods of using a technical specification in a restricted 'domain of applicability', such as Internet routers" (all taken from the definition in 2026 of what goes in a Standards Track document). The document can also clearly evolve over time as we get implementation experience. Making it Standards Track would also given an overt indication of IETF consensus. However, if this document simply exists to give a list of implementation compliance rules for the IPv6 Ready Logo, it should stay Informational, something about that should be said in the Introduction, and this document should not refer to 2119. If it wants to use MUSTs and SHOULDs for compliance language, it needs to redefine those terms at the top. In particular, my comments below in WPD-3 and 6RD-7 indicate two places where 2119 is probably being used incorrectly to specify implementation choices (in the first case for logging features, in the second case for default configuration), which might indicate that this document is really about implementation compliance and not about interoperability. I'm honestly fine with it either way, but the document needs to be clear about what it's doing, and then to stick to that intention. |
2012-08-23
|
10 | Pete Resnick | [Ballot comment] [Updating given replies from the authors/shepherd] 3.1: Perhaps it should be made clearer (either by separating it out or by signposting it a … [Ballot comment] [Updating given replies from the authors/shepherd] 3.1: Perhaps it should be made clearer (either by separating it out or by signposting it a bit better) that this section is more about the current state of deployment than it is about the desired architecture. It caused me a bit of confusion, thinking that this was talking about what was desired, not simply what is. 4.2: W-6: "SHOULD support PCP"? Why not MUST? What circumstances are there where you think it may be reasonable not to support PCP? I think you at least should explain. W-6 (Also S-1 in 4.5): I don't understand why you need to explicitly "take no position on whether such functionality is enabled by default or mechanisms by which users would configure the functionality". Either you're saying something vacuous (in that "we are not putting requirements on user interface elements", which we don't do in the IETF anyway), or you're inserting some judgement, but in a backhanded way, ("I'm not saying you have to turn the stuff on (wink wink nod nod)") I'd rather see that sentence deleted. WAA-5: Why SHOULD the router implement NTP? A short explanation in the document would probably be useful. WPD-3: "SHOULD log a system management error" seems like it is not a requirement that is "actually required for interoperation or to limit behavior which has potential for causing harm". Please get rid of the 2119. 4.3: ULA-3: Strike the word "user". You want the prefix to be configurable. Whether it's a user interface element is irrelevant. 4.4.1: 6RD-7: Is the "MUST" really required? Why not "SHOULD"? Or maybe (if the "MUST" only applies to configured defaults) the 2119 language should simply be removed. |
2012-08-23
|
10 | Pete Resnick | Ballot comment and discuss text updated for Pete Resnick |
2012-08-21
|
10 | Meral Shirazipour | Request for Telechat review by GENART Completed: Almost Ready. Reviewer: Meral Shirazipour. |
2012-08-21
|
10 | Pete Resnick | [Ballot discuss] I would prefer to see this document as a Standards Track document. It "identifies the relevant technical specifications (TSs) and the specific way … [Ballot discuss] I would prefer to see this document as a Standards Track document. It "identifies the relevant technical specifications (TSs) and the specific way in which they are to be combined", it specifies "particular values or ranges of TS parameters or subfunctions of a TS protocol that must be implemented", and it specifies "particular methods of using a technical specification in a restricted 'domain of applicability', such as Internet routers" (all taken from the definition in 2026 of what goes in a Standards Track document). The document can also clearly evolve over time as we get implementation experience. Making it Standards Track would also given an overt indication of IETF consensus. Informational seems like the wrong status for this document. |
2012-08-21
|
10 | Pete Resnick | [Ballot comment] 3.1: A typical IPv4 NAT deployment by default blocks all incoming connections. Opening of ports is typically allowed using a Universal … [Ballot comment] 3.1: A typical IPv4 NAT deployment by default blocks all incoming connections. Opening of ports is typically allowed using a Universal Plug and Play Internet Gateway Device (UPnP IGD) [UPnP-IGD] or some other firewall control protocol. Shouldn't PCP be mentioned here since it is our soon-to-be standardized way of doing things, whereas UPnP is not? Another consequence of using private address space in the end-user network is that it provides stable addressing; i.e., it never changes even when you change service providers, and the addresses are always there even when the WAN interface is down or the customer edge router has not yet been provisioned. I think this is overstated. Yes, private address space *can* provide stable address space, allowing you to keep the same addresses even when you change service providers, but that's only one mode of deployment. Furthermore, public address space can be statically configured so that the addresses are there even when the WAN interface is down, can't it? Seems like this paragraph is trying to sell private address space. Rewriting addresses on the edge of the network also allows for some rudimentary multihoming, even though using NATs for multihoming does not preserve connections during a fail-over event [RFC4864]. If you were in the mood, some mention of MPTCP could be made, as it does preserve connections during fail-over. Many existing routers support dynamic routing... Can I presume that the audience for this document will know what that means without reference? I sure don't, but heck, I'm an apps guy. 4.2: W-6: "SHOULD support PCP"? Why not MUST? What circumstances are there where you think it may be reasonable not to support PCP? I think you at least should explain. Also, I don't understand why you need to explicitly "take no position on whether such functionality is enabled by default or mechanisms by which users would configure the functionality". Either you're saying something vacuous (in that "we are not putting requirements on user interface elements", which we don't do in the IETF anyway), or you're inserting some judgement, but in a backhanded way, ("I'm not saying you have to turn the stuff on (wink wink nod nod)") I'd rather see that sentence deleted. WAA-5: Why SHOULD the router implement NTP? Is there a reason that this is a requirement? WPD-3: "SHOULD log a system management error" seems like it is not a requirement that is "actually required for interoperation or to limit behavior which has potential for causing harm". Please get rid of the 2119. 4.3: ULA-3: Strike the word "user". You want the prefix to be configurable. Whether it's a user interface element is irrelevant. 4.4.1: 6RD-7: Is the "MUST" really required? Why not "SHOULD"? |
2012-08-21
|
10 | Pete Resnick | [Ballot Position Update] New position, Discuss, has been recorded for Pete Resnick |
2012-08-16
|
10 | Cindy Morgan | State changed to IESG Evaluation::Revised ID Needed from IESG Evaluation |
2012-08-16
|
10 | Hemant Singh | New version available: draft-ietf-v6ops-6204bis-10.txt |
2012-08-15
|
09 | Martin Stiemerling | [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling |
2012-08-15
|
09 | Ralph Droms | [Ballot discuss] 1. The changes in this document are surprisingly small. Is this document necessary now? Why are the changes to RFC 6204 being made … [Ballot discuss] 1. The changes in this document are surprisingly small. Is this document necessary now? Why are the changes to RFC 6204 being made now? Are we going to see another RFC with incremental revisions in another year? For example, will we see another revision in a few months when more transition technologies are published? 2. W-6 seems premature due to a lack of justification; it seems to be anticipating some future requirement for applications on the CE router that will need PCP. 3. Is it the intention of this document to preclude the use of DHCPv6 PD if neither the M or O bit are set in a received router advertisement? 4. I know I read and approved WPD-5 in RFC 6204. I think I know the intent of WPD-5, but now I'm not sure that the words actually match the intent. I'd like to discuss the intent to make sure I have it right, and then discuss the specific words to agree that they accurately convey that intent. 5. Why was the new constraint added to WPD-6? I see that WPD-6 refers to [I-D.ietf-dhc-dhcpv6-stateful-issues]. Doesn't that document also address several of the other requirements that have been dropped because of lack of dhc WG consensus; e.g., W-5 (and perhaps WPD-5?). 6. How is the use of 6rd and DS-lite controlled -specifically enabled and disabled? |
2012-08-15
|
09 | Ralph Droms | [Ballot comment] 1. In WAA-8: When the CE Router receives the DHCPv6 SOL_MAX_RT … [Ballot comment] 1. In WAA-8: When the CE Router receives the DHCPv6 SOL_MAX_RT option [I-D.droms-dhc-dhcpv6-solmaxrt-update] in a received DHCPv6 Advertise or Reply message it sets its internal SOL_MAX_RT parameter to the value contained in the SOL_MAX_RT option. Why not simply (and consistently) "The CE router must support the SOL_MAX_RT option and request the SOL_MAX_RT option in an ORO." 2. Appendix item 6 is completely opaque to me. "Layer 1" of what? If the reasons for changes are going to be captured in this document, they should be understandable. 3. s/bullets/requirements/ in the appendix. 4. There are several requirements in the text that are not explicitly labeled as such; e.g., from section 4.4.2: The IPv6 CE Router SHOULD implement DS-Lite functionality. Is there a reason for the inconsistency? 5. Suggested revised text for DLW-1: DLW-1: The CE Router MUST support configuration of DS-Lite via the DS-Lite DHCPv6 option [RFC6334]. |
2012-08-15
|
09 | Ralph Droms | [Ballot Position Update] New position, Discuss, has been recorded for Ralph Droms |
2012-08-14
|
09 | Sean Turner | [Ballot discuss] 1) s4.?: Forgive me if the answer to these is buried in a referenced RFC: 1.a) Do we need to say something about … [Ballot discuss] 1) s4.?: Forgive me if the answer to these is buried in a referenced RFC: 1.a) Do we need to say something about special names (draft-cheshire-dnsext-special-names) resolving to loopback addresses? 1.b) Do we need to say something about reserved, private, loopback and unspecified addresses not being sent out on the WAN? 2) s4.3, L-5: We know the not-so-inside joke that nobody implements DHCPv4 with authentication - can we get that changed and actually require DHCPv6 authentication be implemented? In 5 years I don't want to hear that yeah, yeah we mandated but nobody implemented it. 3) s4.2, w-5: Are you saying implementations must use RFC 6355? If so, I think you need a pointer there - otherwise it's unclear what the requirement is. 4) I'm elevating Stephen's last comment (based on the secdir review): Why would it be a good idea to provide the packet filtering features described in RFC 6092 but only allow these firewall rules to be applied prior to decapsulation. It seems that if the user (who may not be well versed in IP tunneling) turns on some firewall/filtering service in a Customer Edge Router, that what the user probably wants is for the filtering rules to be applied to the packets "inside" the tunnel (after decapsulation) and not to packets containing the "outer" tunnel header. I would therefore recommend that S-3 be changed to a "MUST" instead of a "SHOULD". |
2012-08-14
|
09 | Sean Turner | [Ballot comment] 1) s3.1 - 3rd paragraph starts of saying "another consequence of using private address space" but private address space hasn't been explicitly mentioned … [Ballot comment] 1) s3.1 - 3rd paragraph starts of saying "another consequence of using private address space" but private address space hasn't been explicitly mentioned yet. 2) L-5/L-6: probably worth noting that you're talking about RFC 4861 options. 3) s4.4: Why are only these two listed here? It'd be good to say why in the draft. |
2012-08-14
|
09 | Sean Turner | [Ballot Position Update] New position, Discuss, has been recorded for Sean Turner |
2012-08-13
|
09 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2012-08-13
|
09 | Wesley Eddy | [Ballot Position Update] New position, No Objection, has been recorded for Wesley Eddy |
2012-08-13
|
09 | Robert Sparks | [Ballot Position Update] New position, No Objection, has been recorded for Robert Sparks |
2012-08-13
|
09 | Stephen Farrell | [Ballot comment] Three near-discusses to which I'd like to see responses, but I'm going no-objection taking the "perfect is enemy of the good" approach as … [Ballot comment] Three near-discusses to which I'd like to see responses, but I'm going no-objection taking the "perfect is enemy of the good" approach as requested in the writeup, which I think is a reasonable one for this document. - W-6: Why is *use* of PCP a SHOULD? The doucment says the CE device SHOULD use PCP to discover a server but then says that it takes no position on whether PCP is enabled by default. Maybe just saying "When PCP is in use the PCP client SHOULD..." would be better? - Don't you need to note anything about the THIRD_PARTY PCP feature here? I would guess it MUST NOT be supported for the PCP client on the WAN i/f of this kind of device. I can't recall if PCP base already says that or not, but I suspect its worth adding here to the security considerations here just in case. - Please consider the secdir review [1] question as to whether filtering of decapsulated packets is better as a MUST, and if it remains a SHOULD, then say what's the exception. [1] http://www.ietf.org/mail-archive/web/secdir/current/msg03446.html |
2012-08-13
|
09 | Stephen Farrell | [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell |
2012-08-12
|
09 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded for Russ Housley |
2012-08-11
|
09 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel |
2012-08-11
|
09 | Stewart Bryant | [Ballot comment] Brian raises a number of important points. |
2012-08-11
|
09 | Stewart Bryant | [Ballot Position Update] New position, No Objection, has been recorded for Stewart Bryant |
2012-08-09
|
09 | Jean Mahoney | Request for Telechat review by GENART is assigned to Meral Shirazipour |
2012-08-09
|
09 | Jean Mahoney | Request for Telechat review by GENART is assigned to Meral Shirazipour |
2012-08-09
|
09 | Brian Haberman | [Ballot discuss] I have no problems with the publication of this document, but I do have some issues that I would like to see discussed. … [Ballot discuss] I have no problems with the publication of this document, but I do have some issues that I would like to see discussed. 1. RFC 6204 lists Ole Troan as the editor, but this draft does not have his name listed anywhere (author, editor, or contributor). Why is that? 2. Requirement W-6 says that a CE router should support a PCP client on the WAN side. Presumably, this is to interact with a PCP server in the ISP's network. Was there discussion of requiring a PCP server in order to receive requests from hosts on the LAN side? 3. WAA-5 says that a CE router should implement NTP. Is this strictly as a client? What about acting as an NTP server for LAN side hosts? Should the CE router share any NTP servers it learns via the DHCPv6 option with the clients on the LAN side? If so, how? RFC 5908? 4. Section 4.4 discusses the requirements for transition technologies. However, it is unclear as to why 6rd and DS-Lite are the only two mentioned. I would like to see some introductory discussion as to why those two were chosen and others were not. This does not need to be normative, just a brief outline of how the choices came to be. 5. In section 4.5, requirement S-2 was downgraded from a MUST in RFC 6204 to a SHOULD. What was the rationale for that decision? |
2012-08-09
|
09 | Brian Haberman | [Ballot comment] 1. In WLL-3 : s/NCP's/NCPs/. The apostrophe indicates possession and is inappropriate in this context. 2. In section 4.3, bullet 1 : s/ULA's/ULAs/. … [Ballot comment] 1. In WLL-3 : s/NCP's/NCPs/. The apostrophe indicates possession and is inappropriate in this context. 2. In section 4.3, bullet 1 : s/ULA's/ULAs/. 3. In L-11 : I would suggest adding a proper reference for RDNSS and DNSSL options. 4. RFC 2030 is included in the Normative References, but is not referenced anywhere in the text. |
2012-08-09
|
09 | Brian Haberman | [Ballot Position Update] New position, Discuss, has been recorded for Brian Haberman |
2012-08-01
|
09 | Samuel Weiler | Request for Last Call review by SECDIR Completed. Reviewer: Matt Lepinski. |
2012-07-31
|
09 | Ron Bonica | Placed on agenda for telechat - 2012-08-16 |
2012-07-31
|
09 | Ron Bonica | State changed to IESG Evaluation from Waiting for AD Go-Ahead |
2012-07-31
|
09 | Ron Bonica | Ballot has been issued |
2012-07-31
|
09 | Ron Bonica | [Ballot Position Update] New position, Yes, has been recorded for Ronald Bonica |
2012-07-31
|
09 | Ron Bonica | Created "Approve" ballot |
2012-07-11
|
09 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call |
2012-07-09
|
09 | Pearl Liang | IANA has reviewed draft-ietf-v6ops-6204bis-09, which is currently in Last Call, and has the following comments: IANA understands that, upon approval of this document, there … IANA has reviewed draft-ietf-v6ops-6204bis-09, which is currently in Last Call, and has the following comments: IANA understands that, upon approval of this document, there are no IANA Actions that need completion. |
2012-06-28
|
09 | Jean Mahoney | Request for Last Call review by GENART is assigned to Meral Shirazipour |
2012-06-28
|
09 | Jean Mahoney | Request for Last Call review by GENART is assigned to Meral Shirazipour |
2012-06-28
|
09 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Matt Lepinski |
2012-06-28
|
09 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Matt Lepinski |
2012-06-27
|
09 | Amy Vezza | The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Subject: Last Call: (Basic Requirements for IPv6 Customer Edge … The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Subject: Last Call: (Basic Requirements for IPv6 Customer Edge Routers) to Informational RFC The IESG has received a request from the IPv6 Operations WG (v6ops) to consider the following document: - 'Basic Requirements for IPv6 Customer Edge Routers' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-07-11. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies requirements for an IPv6 Customer Edge (CE) router. Specifically, the current version of this document focuses on the basic provisioning of an IPv6 CE router and the provisioning of IPv6 hosts attached to it. The document also covers IP transition technologies. Two transition technologies in RFC 5969's 6rd and RFC 6333's DS-Lite are covered in the document. The document obsoletes RFC 6204, if approved. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-v6ops-6204bis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-v6ops-6204bis/ballot/ No IPR declarations have been submitted directly on this I-D. |
2012-06-27
|
09 | Amy Vezza | State changed to In Last Call from Last Call Requested |
2012-06-27
|
09 | Ron Bonica | Last call was requested |
2012-06-27
|
09 | Ron Bonica | Last call announcement was generated |
2012-06-27
|
09 | Ron Bonica | Ballot approval text was generated |
2012-06-27
|
09 | Ron Bonica | State changed to Last Call Requested from AD Evaluation |
2012-06-27
|
09 | Ron Bonica | State changed to AD Evaluation from Publication Requested |
2012-06-27
|
09 | Ron Bonica | Ballot writeup was changed |
2012-06-27
|
09 | Ron Bonica | Ballot writeup was changed |
2012-06-27
|
09 | Ron Bonica | Ballot writeup was generated |
2012-05-30
|
09 | Amy Vezza | This is the document shepherd writeup for draft-ietf-v6ops-6204bis-09 prepared 5/28/2012. All comments on Basic Requirements for IPv6 Customer Edge Routers draft-ietf-v6ops-6204bis-09 are derived from the … This is the document shepherd writeup for draft-ietf-v6ops-6204bis-09 prepared 5/28/2012. All comments on Basic Requirements for IPv6 Customer Edge Routers draft-ietf-v6ops-6204bis-09 are derived from the IETF tools version: http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-09 The document writeup version is 24 February 2012. 1) The intended status is informational. The document obsoletes RFC 6204 an informational RFC. 2) Technical Summary This document specifies requirements for an IPv6 Customer Edge (CE) router. Specifically, the current version of this document focuses on the basic provisioning of an IPv6 CE router and the provisioning of IPv6 hosts attached to it. Working Group Summary The Bis document follows quickly on the heals of the original RFC 6204 (published April 2011). This speaks both to the rapid ferment associated with transition technologies and their deployment in CPE devices as well as the impact that operational experience is now having on recommendations. Clearly in this case, perfection is the enemy of the good, and timely publication will likely result in issues that need to be revisited or resolved in future documents. The input of the design team was thoroughly discussed on the mailing list resulting in Draft 08 which passed working group last call, with draft 09 addressing issues with 6rd requirements found during and immediately after WGLC. A subsequent and shorter last call was confirmed on tuesday 5/22/2012. There is ongoing discussion around requirements related to setting MSS MTU requirements for transition technologies. Consensus in this area to the extent that it exists is still evolving. Additional work in the form of a draft or drafts may be required and several have already been proposed. Document Quality The document shepherd believes that the document is generally well written. Significant experience with RFC 6204 by implementers and operators resulted in the document that we see here. The Advice provided here is by no-means comprehensive, but with implementers using these guidelines a common expectation for CPE functionality inclusive of transition technologies is seems plausible. Personnel The document shepherd is Joel Jaeggli v6ops co-chair. The responsible area-director is Ron Bonica. 3) The document shepherd has read the document in several iterations. Consultation with the design team extends back to the inception of work on the update to RFC 6204 in mid 2011. 4) The document shepherd has no concerns about the breadth and depth of review. As noted in the working-group summary it seems likely if not inevitable that subsequent documents will amend, or further support the work of specifying expectations for CPE devices. 5) The document has been reviewed by several implementers and operators. As this is not a protocol specification the principle consideration is, does the interpretation of the implementation advice produce a product which we can live with? I believe that we can reasonably conclude that the review is sufficient. 6) As noted in the working group summary, the issue of setting the MTU on tunnel interfaces or rewriting the MSS on traffic passing through a CPE using a transition technology such as 6rd or ds-lite is a contentious one, to that end the document does not directly address the issue through recommendations. As it stands now the discussion spans some 9 threads and 129 messages since 5/112012. 7) No IPR disclosures have been lodged on draft-ietf-v6ops-6204bis. 8) I am not aware of any IPR disclosures that reference this document. 9) The document has had substantial discussion (there are some 1092 messages associated with the document since 8/18/11). No substantive opposition to advancing the document was noted in WGLC. As noted the MTU/MSS issue is still the subject of some debate and there is some petulance associated with the lack of inclusion. It is the opinion of the WG chairs and the authors that this is better addressed in a document specific to the problem or the transition technologies themselves. 10) No appeals appear to be in the offing. Given that there are a broad number of topics covered under the umbrella of CPE requirements, I would think that this document might engender substantial discussion in the IETF last call. The lack of proscriptive instruction on MSS fixup has been noted. 11) Idnits checker indicates unused references, which in fact are used. draft-ietf-dhc-pd-exclude has subsequently been published as RFC 6603, this can be corrected in auth48. Likewise draft-ietf-pcp-base has an updated version. the obsolete reference is obsolete as it was removed when waa-5 was updated to require NTP rather than SNTP. It can be removed. 12) No formal review is considered necessary. 13) References have been divided between normative and informative. 14) There are three normative reference to drafts I-D.ietf-dhc-pd-exclude - published as RFC 6603 And two work in progress drafts I-D.droms-dhc-dhcpv6-solmaxrt-update http://tools.ietf.org/html/draft-droms-dhc-dhcpv6-solmaxrt-update-02 I-D.ietf-pcp-base http://tools.ietf.org/html/draft-ietf-pcp-base-24 The DHC WG document is in last call and will likely be following this draft momentarily. as with 6204bis changes to the DHCPv6 specification are borne out of operational experience and these two documents are significantly related. 15) As this document is informational, there are no down-references. 16) The document draft-ietf-v6ops-6204bis naturally obsoletes rfc6204. No other documents are altered by it's publication. 17) No consideration on the part of IANA is required. 18) No IANA registries are created. 19) No formal language is present in the document. |
2012-05-30
|
09 | Amy Vezza | Note added 'The document shepherd is Joel Jaeggli (joelja@bogus.com).' |
2012-05-30
|
09 | Amy Vezza | Intended Status changed to Informational |
2012-05-30
|
09 | Amy Vezza | IESG process started in state Publication Requested |
2012-05-30
|
09 | (System) | Earlier history may be found in the Comment Log for draft-ietf-v6ops-ipv6-cpe-router-bis |
2012-05-16
|
09 | Hemant Singh | New version available: draft-ietf-v6ops-6204bis-09.txt |
2012-04-06
|
08 | Hemant Singh | New version available: draft-ietf-v6ops-6204bis-08.txt |
2012-03-08
|
07 | Hemant Singh | New version available: draft-ietf-v6ops-6204bis-07.txt |
2012-03-06
|
06 | Hemant Singh | New version available: draft-ietf-v6ops-6204bis-06.txt |
2011-12-22
|
05 | (System) | New version available: draft-ietf-v6ops-6204bis-05.txt |
2011-12-05
|
04 | (System) | New version available: draft-ietf-v6ops-6204bis-04.txt |
2011-11-22
|
03 | (System) | New version available: draft-ietf-v6ops-6204bis-03.txt |
2011-10-31
|
02 | (System) | New version available: draft-ietf-v6ops-6204bis-02.txt |
2011-10-18
|
01 | (System) | New version available: draft-ietf-v6ops-6204bis-01.txt |
2011-10-07
|
00 | (System) | New version available: draft-ietf-v6ops-6204bis-00.txt |