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

From: Tim Chown <[email-masked]>
Date: Mon, 31 Oct 2016 15:27:30 +0000

Hi,

As discussed at IETF96, Tim, John and I have posted a (quite rough) RFC6434-bis -00 draft.

The body of this -00 text is unchanged from RFC6434, with the exception that the author and acknowledgment text has been updated.

We have discussed potential changes, and reviewed 6MAN publications since RFC6434 was published.

Rather than editing the RFC6434 text, we have instead added a number of “comments" in the new -00 text delimited by 

**BIS …blah blah… ** 

in standalone paragraphs which loosely describe the changes that we think could be made, with the idea of getting some initial high level feedback and consensus on those potential changes. We will refine the “comments" into real changes to the body of the text in a future version, assuming we can see that the changes have consensus, or at least no objections.

At this stage, what would be useful is review of the appropriateness of the “comments”, and suggestions for any further things to be added, changed, or removed, if only at a high level at this point, though suggested document text is always welcome.

We’ve requested a short slot in Seoul to move the work forward.

Tim 

> On 31 Oct 2016, at 15:05, [email-masked] wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
>        Title           : IPv6 Node Requirements
>        Authors         : Tim Chown
>                          John Loughney
>                          Tim Winters
> 	Filename        : draft-clw-rfc6434-bis-00.txt
> 	Pages           : 34
> 	Date            : 2016-10-31
> 
> Abstract:
>   This document defines requirements for IPv6 nodes.  It is expected
>   that IPv6 will be deployed in a wide range of devices and situations.
>   Specifying the requirements for IPv6 nodes allows IPv6 to function
>   well and interoperate in a large number of situations and
>   deployments.
> 
>   This document obsoletes RFC 6434, and in turn RFC 4294.
> 
>   NB.  This is a first -00 version of the update to RFC 6434.  We have
>   not yet edited original text from RFC 6434 apart from the author and
>   acknowledgement texts, which carry forward from the older versions.
> 
>   We have indicated intended changes (additions, updates or deletion of
>   text at a high level in the sections below with text delimited by
>   **BIS ... ** comments, e.g.
> 
>   **BIS Add discussion of the impact of RFC xxxx **
> 
>   **BIS Update reference of RFC 3484 and note new address selection
>   implications**
> 
>   etc.  These will become edits in future versions once the substance
>   of the changes is agreed.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-clw-rfc6434-bis/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-clw-rfc6434-bis-00
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 31 Oct 2016 16:44:34 +0100

Hi Tim,

Should IPv6 nodes include support for some transition mechanisms? I’ve my doubts myself in this case, specially because actual OS have it (minimum 6in4, sometimes many others), even some cellular phones (Android and Windows) include support for 464XLAT.

Same question for IPv6 routers ? Here I will say is a must. What is the sense of a router today, not supporting at least a few transition mechanisms, in order to facilitate the ISPs that run out of IPv4 addresses to keep deploying IPv6 (464XLAT, MAP, …)?

Regards,
Jordi

-----Mensaje original-----
De: ipv6 <[email-masked]> en nombre de Tim Chown <[email-masked]>
Responder a: <[email-masked]>
Fecha: lunes, 31 de octubre de 2016, 16:27
Para: "[email-masked]" <[email-masked]>
Asunto: Re: I-D Action: draft-clw-rfc6434-bis-00.txt

    Hi,

    

    **BIS …blah blah… ** 

    
    
    Tim 
    
    > ftp://ftp.ietf.org/internet-drafts/
    
    --------------------------------------------------------------------
    IETF IPv6 working group mailing list
    [email-masked]
    Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    --------------------------------------------------------------------

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

---

From: Fred Baker <[email-masked]>
Date: Mon, 31 Oct 2016 09:04:06 -0700

Speaking for myself, I would think that is a market issue, not a standards issue. It would be strange to be requiring 6rd or whatever after IPv4 has been shut down. I would rather let markets determine their requirements.

> On Oct 31, 2016, at 8:44 AM, JORDI PALET MARTINEZ <[email-masked]> wrote:
> 
> Hi Tim,
>

---

From: Timothy Winters <[email-masked]>
Date: Mon, 31 Oct 2016 12:09:16 -0400

Maybe we can mention what transition mechanisms exist and the use cases for
the transition mechanism, but not recommend any?

~Tim

On Mon, Oct 31, 2016 at 12:04 PM, Fred Baker <[email-masked]>
wrote:

> Speaking for myself, I would think that is a market issue, not a standards
> issue. It would be strange to be requiring 6rd or whatever after IPv4 has
> been shut down. I would rather let markets determine their requirements.
>
> > Should IPv6 nodes include support for some transition mechanisms? I’ve
> my doubts myself in this case, specially because actual OS have it (minimum
> 6in4, sometimes many others), even some cellular phones (Android and
> Windows) include support for 464XLAT.
> >
> > Same question for IPv6 routers ? Here I will say is a must. What is the
> sense of a router today, not supporting at least a few transition
> mechanisms, in order to facilitate the ISPs that run out of IPv4 addresses
> to keep deploying IPv6 (464XLAT, MAP, …)?
> >
> > Regards,
> > Jordi
> >
> >
> >    The body of this -00 text is unchanged from RFC6434, with the
> exception that the author and acknowledgment text has been updated.
> >
> >    Rather than editing the RFC6434 text, we have instead added a number
> of “comments" in the new -00 text delimited by
> >
> >    **BIS …blah blah… **
> >
> >    in standalone paragraphs which loosely describe the changes that we
> think could be made, with the idea of getting some initial high level
> feedback and consensus on those potential changes. We will refine the
> “comments" into real changes to the body of the text in a future version,
> assuming we can see that the changes have consensus, or at least no
> objections.
> >
> >    At this stage, what would be useful is review of the appropriateness
> of the “comments”, and suggestions for any further things to be added,
> changed, or removed, if only at a high level at this point, though
> suggested document text is always welcome.
> >
> > This electronic message contains information which may be privileged or
> confidential. The information is intended to be for the use of the
> individual(s) named above. If you are not the intended recipient be aware
> that any disclosure, copying, distribution or use of the contents of this
> information, including attached files, is prohibited.
> >
> >
> >

-- 

Now offering testing for SDN applications and controllers in our SDN switch
test bed. Learn more today http://bit.ly/SDN_IOLPR

---

From: Lee Howard <[email-masked]>
Date: Mon, 31 Oct 2016 13:41:16 -0400

>Same question for IPv6 routers ? Here I will say is a must. What is the sense of a router today, not supporting at least a few transition mechanisms, in order to facilitate the ISPs that run out of…

Most routers do not need to support any transition mechanism: they will continue to run IPv4, IPv6, or both. Only those that actually terminate the tunnel or do the translation will need to support the transition mechanism. 

In fact, there are no nodes that MUST implement a transition mechanism in order to support IPv6, which is the scope of the document. "IPv6 nodes MAY support IPv4." is good enough for me.

Lee

---

From: Lee Howard <[email-masked]>
Date: Mon, 31 Oct 2016 13:42:25 -0400

From:  ipv6 on behalf of Timothy Winters
Date:  Monday, October 31, 2016 at 12:09 PM
To:  Fred Baker
Cc:  <[email-masked]>
Subject:  Re: I-D Action: draft-clw-rfc6434-bis-00.txt

Maybe we can mention what transition mechanisms exist and the use cases for the transition mechanism, but not recommend any?

That would be incredibly useful, in a separate document. It could easily take 20 pages.

Lee

~Tim

On Mon, Oct 31, 2016 at 12:04 PM, Fred Baker <[email-masked]> wrote:
Speaking for myself, I would think that is a market issue, not a standards issue. It would be strange to be requiring 6rd or whatever after IPv4 has been shut down. I would rather let markets determine their requirements.

-- 
Now offering testing for SDN applications and controllers in our SDN switch test bed. Learn more today http://bit.ly/SDN_IOLPR
-------------------------------------------------------------------- IETF IPv6 working group mailing list [email-masked] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 31 Oct 2016 19:01:36 +0100

I will agree with you if this is an STD document, but being an Informational one, I think it make sense to say something.

We can clarify that the support of the transition mechanism is while it is required by the ISP deploying those products while there is still a dependency on IPv4.

Saludos,
Jordi

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 31 Oct 2016 19:17:04 +0100

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.

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.

Saludos,
Jordi

-----Mensaje original-----
De: Lee Howard <[email-masked]>
Responder a: <[email-masked]>
Fecha: lunes, 31 de octubre de 2016, 18:41
Para: <[email-masked]>, <[email-masked]>
Asunto: Re: I-D Action: draft-clw-rfc6434-bis-00.txt

    

    

    Lee

---

From: Lee Howard <[email-masked]>
Date: Mon, 31 Oct 2016 15:22:36 -0400

>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).

>   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 stab…

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.

Lee

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 1 Nov 2016 17:11:48 +1300

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.

Regards
   Brian