Re: [v6ops] draft-palet-v6ops-transition-ipv4aas discussion

Lee Howard <lee@asgard.org> Wed, 18 April 2018 18:17 UTC

Return-Path: <lee@asgard.org>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 521511200FC for <v6ops@ietfa.amsl.com>; Wed, 18 Apr 2018 11:17:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.234
X-Spam-Level:
X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7mDobuVuQ_6U for <v6ops@ietfa.amsl.com>; Wed, 18 Apr 2018 11:17:36 -0700 (PDT)
Received: from atl4mhob15.registeredsite.com (atl4mhob15.registeredsite.com [209.17.115.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0E6F1242F5 for <v6ops@ietf.org>; Wed, 18 Apr 2018 11:17:35 -0700 (PDT)
Received: from mailpod.hostingplatform.com (atl4qobmail01pod6.registeredsite.com [10.30.71.209]) by atl4mhob15.registeredsite.com (8.14.4/8.14.4) with ESMTP id w3IIHWZ4024196 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for <v6ops@ietf.org>; Wed, 18 Apr 2018 14:17:32 -0400
Received: (qmail 31223 invoked by uid 0); 18 Apr 2018 18:17:32 -0000
X-TCPREMOTEIP: 174.64.33.182
X-Authenticated-UID: lee@asgard.org
Received: from unknown (HELO ?192.168.2.100?) (lee@asgard.org@174.64.33.182) by 0 with ESMTPA; 18 Apr 2018 18:17:32 -0000
To: v6ops@ietf.org
References: <3A083AA8-41D3-4BF8-BE31-5071975B6F98@gmail.com>
From: Lee Howard <lee@asgard.org>
Message-ID: <43764aef-3aef-4269-cba8-94685ee4673f@asgard.org>
Date: Wed, 18 Apr 2018 14:17:31 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <3A083AA8-41D3-4BF8-BE31-5071975B6F98@gmail.com>
Content-Type: multipart/alternative; boundary="------------F6ED387542371A567D29E323"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/rkw8rf54CypoBv13WO_uK1VM9eE>
Subject: Re: [v6ops] draft-palet-v6ops-transition-ipv4aas discussion
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Apr 2018 18:17:40 -0000

I think this document is needed.

When ISPs buy equipment for customers, they can specify which set of 
features they want.

When customers buy their own equipment, they can choose from whatever is 
on the shelf.

In order to effect a transition to IPv6, customer edge routers will need 
to support transition mechanisms. Since a CE router manufacturer can't 
know which transition mechanism will be used by any/all ISPs in the 
market where it will need to be sold, they will need to support the most 
likely mechanisms.

So, this document specifies behavior for retail-marketed devices, not 
buyer-specified devices. If an ISP wants fewer features to save cost or 
for security, she may specify that. It means that CE router is less 
likely to work if the consumer takes it to a competitor ISP, but I can 
live with that.

Comments on the document:

Introduction, Paragraph 3:

It's a run-on sentence that makes the features sound unnecessary until 
there is an IPv6-only network in place. Since CE routers have a lifetime 
of 7-15 years, I think that's too late. Suggest rewording it to:

This document covers the IP transition technologies required when
    ISPs have an IPv6-only access network. This is a
    common situation in a world where IPv4 addresses are no longer
    available, so the service providers need to provision IPv6-only WAN
    access. At the same time, they need to ensure that both IPv4-only and
    IPv6-only devices or applications in the customer networks, can still
    reach IPv4-only devices or applications in the Internet.

Paragraph 7:
Based on my comments above, I would like to reword this paragraph to:

    Service providers who specify feature sets for CE routers may specify
    a different set of features than those included in this document.
    Since it is impossible to know prior to sale which transition
    mechanism a device will need over the lifetime of the device, IPv6 CE
    transition routers intended for the retail market must support all
    of them.


I agree with the note in 1.1 Requirements Language, but almost glossed 
over it because it looks at first like RFC2119 boilerplate. Maybe revise 
the heading to "Requirements Language - Special Note"? Also, 
"preferable" should be "preferably."

I'm using the same language in comments that you do in the document, but 
"IPv6 transition Customer Edge Router with IPv4aaS" is long, and even 
the shortened version is cumbersome. Can we revise the terminology to 
say that "CE Router" used in this document means "a Customer Edge router 
with support for IPv6 transition mechanisms," unless specified as "a CE 
Router without transition mechanism support"? Also, need to expand the 
acronym "IPv4aaS" and define it.

3. Usage Scenarios
I'm not sure this section is needed; I think you've successfully made 
this argument earlier in the document, and I think anyone with even a 
faint familiarity with the transition understand the points being made 
here. If you disagree and want to keep it:

Paragraph 1 nit:  "situation before described" -> "situation previously 
described" or "situation described above".

Paragraph 2 nit: "may be" -> "it may be that"

"customer churn. . . " would read better as:

    consumers may switch ISPs and use the same CE router with an ISP that
    provides IPv4-only and an ISP that provides IPv6 plus IPv4aaS.


Paragraph 3 nit: "it is required an IPv6 transition CE" -> "an IPv6 
transition CE is required that"

"accommodating to" -> "accommodate"

Remove "as it may be or not provided by the service provider"

I'd remove the sentence "Even may be a point..." Not only is it 
grammatically impenetrable, increasing competition isn't a goal of this 
document (or of the IETF, or operators, or CE vendors).

The "Moreover" paragraph:

    Moreover, because some services will remain IPv4-only for an
    undetermined time, and some service providers will remain IPv4-only
    for an undetermined period of time, IPv4 will be needed for an
    undetermined period of time. There will be a need for CEs
    with support "IPv4 as a Service" for an undetermined period of time.


As I said above, I don't think the numbered list is needed, especially 
when four of them are the same, and two others are the same. I don't 
know what "exporting services to the WAN" means. Does this just mean 
"allowing inbound connections"?

The "The main difference" paragraph seems to say that, but it doesn't 
quite. I think if you're going to sidestep the issue of allowing inbound 
connections, you need to be much more explicit about it. For instance:

    An IPv6 transition CE might allow inbound connections over IPv6,
    with appropriate firewall rules and DNS entries. Several IPv4aaS
    implementations do not allow for port forwarding to CE routers,
    and the configuration and troubleshooting of port forwarding may
    be complicated.


The "For example" paragraph adds no clarity. The number of users has no 
bearing on the functionality, at least as far as you've described.

Second-to-last paragraph: "aspects" should be "features"

I'd rewrite the sentence "In fact, in many cases" to:

    In fact, in many cases, the user must supply or may replace
    the IPv6 Transition CE router; this makes even more
    relevant that all the IPv6 Transition CE routers support the same
    requirements defined in this document.


Last paragraph of Section 3: "may have" -> "they may have"

Section 4. End-User Network Architecture
"precedent" -> "preceding"

"behind it" -> "upstream"

4th paragraph: "the latest" -> "that"
Although I'm not sure why PCP isn't part of the sentence with UPnP-IGD, 
and from the previous section, I thought you weren't going to discuss this.

The "Another consequence" paragraph seems to say that IPv4+NAT is a 
feature for address stability, but then falls silent on address 
stability in IPv6. I know you don't want to say ULA (and I don't want to 
make it a target for Lorenzo), but if you're going to say anything, you 
have to be honest about it.

"Many existing routers support dynamic routing."  What? Consumer Edge 
routers? That is not my experience at all, and if it were common, we 
could have avoided two years of fighting in Homenet.

In the requirements section, I would like to see every instance of an 
RFC number accompanied by the title of that RFC. It helps with context. 
Plus, every requirement needs text explaining why it is a requirement. 
Sections 5.1 and 5.2 do neither of those.

The first two sentences of 5.3 Transition Technologies Support... are 
broken up poorly. Suggest:

    The main target of this document is the support of IPv6-only WAN
    access. To enable legacy IPv4 functionality, this document also
    includes the support of IPv4-only devices and
    applications in the customers LANs, as well as IPv4-only services
    on the Internet. Thus, both IPv4-only and the IPv6-only devices
    inside the CE are able to reach the IPv4-only services.


It makes me wonder that we don't need a solution for IPv4-only devices 
to reach IPv6-only services/content on the Internet. I suppose the 
market means that's not required, and frankly I'm satisfied with EOLing 
IPv4-only devices as content moves to IPv4-meh. We could in theory 
include CLAT by itself?

I don't think IPv6 "Service Continuity" should be capitalized.

464XLAT-1

unless there is a match with a valid
                OPTION_S46_PRIORITY

Shouldn't the CE Router process those options in order, and once one 
works, stop? Wouldn't it be clearer to say it that was in TRANS-1, and 
not have to repeat it later?

464XLAT-3

In environments with PCP support

How do you know if there's PCP support?

Section 5.3.2 says "If DS-Lite is implemented, lw4o6 MUST be supported 
as well." Why?

I like sections 7 Code Considerations and 8 Security Considerations. You 
might mention the Security Considerations sections of each of the 
transition mechanism RFCs, too.

I would be in favor of removing the 6rd requirement implied by RFC7048. 
If anyone is planning 6rd deployments, I'd be very surprised.

Lee



On 04/15/2018 01:00 AM, Fred Baker wrote:
> At IETF 101, Jordi Palet Martinez presented draft-palet-v6ops-transition-ipv4aas. The draft is at https://tools.ietf.org/html/draft-palet-v6ops-transition-ipv4aas, and his presentation deck is at https://datatracker.ietf.org/meeting/101/materials/slides-101-v6ops-transition-requirements-for-ipv6-ce-routers-to-support-ipv4-as-a-service-00.
>
> I would like to invite discussion.
>
> In particular, this draft derives from draft-ietf-v6ops-rfc7084-bis, and the chairs wonder if it should be reposted as the next version of draft-ietf-v6ops-rfc7084-bis. That should happen if an only if the working group thinks it should be published as an RFC (now or at some point) adding considerations for implementors of RFC 7084 and also implementing transition services.
>
> A key comment at IETF 101 was that there remain far too many transition mechanisms listed. It would be helpful, if you hold that opinion, if you could give that advice, identify the mechanism or mechanisms you think should be listed, and indicate the reasoning behind your viewpoint. For example, if you think MAP-T should be listed, it would be helpful to know what operators are implementing MAP-T and are looking for CE Routers that support it. The same comment applies to any such mechanism or service.
>
>
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops