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

[JORDI PALET MARTINEZ <[e-mail]>]

Hi Lee,

 

Thanks a lot for your comments.

 

I will review them in detail in a couple of days, in case there are other inputs, so we can work out a new version and hopefully publish already as WG item.

 

Anyway, I’ve read all them and I think I agree in most of them.

 

I’ve now only a few quick comments/question, in order to help with a good review of our actual text:
I think this document is also for small and medium ISPs, only big ones have the power to specify the set of features they need. Not sure if your second sentence disagree with that.
1.1 was taken from RFC7084. Do you think it will be better to use the standard RFC2119 boilerplate?
I think the usage scenarios is important to readers that may be don’t have a clear view on what is the CE we are talking about, and in fact it was requested in one of the previous v6ops presentations. Anyway, I will try to make it more “compressed”.
The “dynamic routing” comes from the original rfc7084, which turned into the rfc7084-bis. I will check that from all my version history on this document … and clarify or delete it.
I’m not 100% sure to understand your comment on the CLAT. I think one of the keys is to allow deploying IPv6-only access while users still can use devices in their LANs until they have incentives to replace them, otherwise, customers will complain when they get IPv6-only services (if using CLAT it is transparent for them). CLAT can provide a NAT46, but then we need a also DNS46 ? If I got you correctly, it is good that there is an incentive for replacing IPv4-only devices because at some point there may be IPv6-only services … so I think we should not make any new transition mechanism to solve that problem?
I think you mean “IPv4 service continuity” (not capitalized)
Regarding 6rd, you mean this document should update RFC7084 and remove 6rd requirements? I will agree on that …
 

Thanks!


Regards,

Jordi

 

 

De: v6ops <[e-mail]> en nombre de Lee Howard <[e-mail]>
Fecha: miércoles, 18 de abril de 2018, 20:18
Para: <[e-mail]>
Asunto: Re: [v6ops] draft-palet-v6ops-transition-ipv4aas discussion

 

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
[e-mail]
https://www.ietf.org/mailman/listinfo/v6ops

_______________________________________________ v6ops mailing list [e-mail] https://www.ietf.org/mailman/listinfo/v6ops 



**********************************************
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 exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.