Subject: Re: I-D Action: draft-clw-rfc6434-bis-00.txt

From: Tim Chown <[email-masked]>
Date: Sat, 12 Nov 2016 11:10:08 +0000

Hi,

> On 31 Oct 2016, at 19:22, Lee Howard <[email-masked]> wrote:
> 
> On 10/31/16, 2:17 PM, "ipv6 on behalf of JORDI PALET MARTINEZ" <[email-masked] on behalf of [email-masked]> wrote:
> 
>> I’m referring to the CPEs deployed in residential network, which clearly are the ones that sell more units, so it is key to say something.
> 
> That would be clearer (but see below).
> 
>> 
>> Also I will say that instead of 
>> 
>> 
>> 8.  IPv4 Support and Transition
>> 
>>  IPv6 nodes MAY support IPv4.
>> 
>> 
>> We say:
>> 
>>  IPv6 nodes MAY support IPv4. In that case, they MUST support one or several transition mechanisms, in cases they are targeted to be deployed at edge networks that don’t require a public IPv4 stable address (residential networks, some corporate networks), while the ISPs still need to provide access to IPv4 for applications or services inside the customer LAN(s). For instance, if the ISP is providing only IPv6 in the access, they may choose among several options such as DS-Lite, lw4o6, 464XLAT (CLAT), MAP-T or MAP-E.
> 
> As you have it written, nodes MUST support one or more of (twenty-seven different transition mechanisms), but it is unclear who chooses (the ISP or the manufacturer) or how many.
> 
> I think this is an inappropriate use of MUST, based on guidance from rfc2119:
> 
> Imperatives of the type defined in this memo must be used with care
> and sparingly.  In particular, they MUST only be used where it is
> actually required for interoperation or to limit behavior which has
> potential for causing harm (e.g., limiting retransmisssions)  For
> example, they must not be used to try to impose a particular method
> on implementors where the method is not required for
> interoperability.
> 
> Implementation of one or more transition mechanisms might be required for interoperability, but only if the node is deployed in a network (and in a position) where that particular mechanism is used, and is deployable.
> 
> Also, rfc6540 (IPv6 Support Required for All IP-Capable Nodes) already includes:
>   o  New and updated IP networking implementations should support IPv4
>      and IPv6 coexistence (dual-stack), but must not require IPv4 for
>      proper and complete function.
> 
> I think requiring a transition mechanism is out of place in this document.

I agree, but we have a 15 min slot in 6man this week so can raise it there to check consensus.

I would also agree that a separate BCP on transition mechanisms would be reasonably useful, given the zillions of mechanisms that have been published through the IETF and the number that are pretty much extinct in practice.  It would still be a moving target though.

Tim

---

From: Tim Chown <[email-masked]>
Date: Mon, 14 Nov 2016 01:59:59 +0000

Hi Brian,

> On 1 Nov 2016, at 04:11, Brian E Carpenter <[email-masked]> wrote:
> 
> Thanks for this. One small gap:
> 
> draft-ietf-6man-multi-homed-host (in RFC Editing) updates RFC 4861 behaviour
> for both hosts and routers, so probably needs to be cited where 4861 is cited.
> 
> It also interacts with rule 5.5. of RFC6724, so should possibly also be
> mentioned under Default Address Selection too.
> 
> I also wondered whether it's worth adding two Appendices
> 1) list of obsoleted documents
> 2) list of "other reading" - useful documents that are not part of the
> normative set.

These are good suggestions.

Thanks,
Tim