Skip to main content

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