Re: [v6ops] draft-ietf-v6ops-6204bis WGLC

[Ole Trøan <[e-mail]>]

> This is to initiate a two week working group last call of draft-ietf-v6ops-6204bis. Please read it now. If you find nits (spelling errors, minor suggested wording changes, etc), comment to the authors; if you find greater issues, such as disagreeing with a statement or finding additional issues that need to be addressed, please post your comments to the list. The draft will be on the agenda at IETF 83, and I would like to send the authors home with a work plan to complete it if it is not to the WG's liking.
> 
> We are looking specifically for comments on the importance of the document as well as its content. If you have read the document and believe it to be of operational utility, that is also an important comment to make.

I've done a review of the bis document against RFC6204. please find my comments below.

Major:
======

1. The DHCP "problem".
   UNH testing uncovered quite a few issues with the 3315/3633 protocol specifications with
   regards to support for both IA_NA and IA_PD. these issues are debated in DHC and there will be a DHC
   bar/DT meeting to see if those issues can be resolved and how. 6204bis depends on the outcome of this and
   shouldn't proceed before we know what requirements to make on DHCP.
   This is a problem we need to solve, and I don't think we can be silent on it.
   (e.g. bis has removed 6204, W-5. this also affects WPD-6.)
   Suggestion: Await resolution in DHC and adopt requirements accordingly.

2. PCP text is incomplete. As specified PCP support in the document is incomplete.
   If this has been added for DS-lite support draft-dupont-pcp-dslite-01
   should be referenced. Currently the requirement is not testable. E.g.
   it doesn't even specify which PCP server the client should use.
   In my opinion it also need to specify PCP/proxy LAN side behavior.
   (or reference a homenet document if one existed)
   Suggestion: Get thorough review in PCP and HOMENET. Incorporate LAN side requirements.

3. Section 4.4.1: transition mechanisms for IPv6. in introducing 6rd, 
   a CE might end up being multi-homed. that opens up
   a can of worms that the draft is silent on. either include the requirements from
   draft-townsley-troan-ipv6-ce-transitioning-02 incorporated or specify that native an 6rd are mutually
   exclusive.
   Suggestion: Incorporate requirements from above draft.

4. life-extension mechanisms for IPv4. firstly I don't think this mechanism belongs in this document, which 
   is all about delivering IPv6 service, while DS-lite is all about delivering IPv4 service.
   in addition to creating the same multi-homing issue (now for IPv4) above, it also has missing pieces.
   e.g. assigning full global addresses, something that is being worked on in softwire. fourthly (have I got
   that far) there are a number of proposals in softwires for complementary / competing mechanisms for
   IPv4 life extensions. NAT464, MAP-{T,E}, 4rd-U. there is also SD-NAT which achieves the same, but doesn't
   use IPv6 transport at all. I would prefer that none of these was in _this_ document, but that we had a separate
   document for "Life extensions for IPv4 CEs"

Minor:
======

1. Section 3.2.1: Why is this section removed?
   A dual-stack host is multihomed to IPv4 and IPv6 networks. The IPv4 and IPv6 topologies
   may not be congruent, and different addresses may have different reachability, e.g., ULAs.
   A host stack has to be able to quickly fail over and try a different source address and destination
   address pair if communication fails, as outlined in [HAPPY-EYEBALLS].
   Suggestion: Add back the missing paragraph.

2. W-3. Question: is there a need for "Router Discovery" to continue forever?
   Compared to todays behavior where it times out after 3 attempts?

3. WAA-4. Has added support for the DNS Search List option.
   The CPE acts as a demarcation point between two administrative domains.
   It will pass some information learnt from the WAN side DHCP client to its LAN
   side DHCP server. I think it is a particularly bad idea to let the ISP set the
   DNS search lists for hosts within my home.
   Why is this option added and what is the use case?
   Suggestion: Remove requirement for DNSSL

4. RFC6204 WAA-7 has been removed. Is that a good idea?
   I think this point is important to make it clear that RA and DHCP processing
   can be done independently of each other.
   Suggestion: Add requirement back.

5. New WAA-7. I think the added "unless configured to require a global IPv6
   address on the WAN interface.", dilutes the purpose of that requirement.
   The RFC6204 profile is meant to result in a router that can be plugged into any
   access network. Even though certain access networks will not operate the unnumbered
   addressing model, how are we going to ensure that no user moves this CPE to
   another access network, that requires it?
   How is this additional "unless configured" testable?
   This same comment applies to WPD-6.
   Suggestion: Remove addition text on WPD-6 and WAA-7.

6. WPD-1. Generally we have tried to avoid having multiple 2119 keywords in one
   requirement. Make PD-exclude a separate requirement.
   Suggestion: Split requirement in two.

7. WPD-4. I disagree with this requirement. It is also hard to test, and becomes
   meaningless, given that a CPE must do PD even if M=0, O=0.
   Suggestion: revert back to RFC6204:WPD-4