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

[Lee Howard <[e-mail]>]

On 04/18/2018 03:34 PM, JORDI PALET MARTINEZ wrote:
>
> 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:
>
>  1. 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.
>

Yes, I agree. If it sounded like I didn't agree, I misspoke. Small ISPs 
can select vendors who provide the features they want, but because of 
their small purchases, they cannot specify new features.

>  1. 1.1 was taken from RFC7084. Do you think it will be better to use
>     the standard RFC2119 boilerplate?
>

No, I agree with the wording. I just think it's important to note the 
difference for people who read a lot of RFCs.
>
>  1. 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”.
>  2. 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.
>  3. 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?
>

Yes, you're right. Nevermind.
>
>  1. I think you mean “IPv4 service continuity” (not capitalized)
>

Yes.

>  1. Regarding 6rd, you mean this document should update RFC7084 and
>     remove 6rd requirements? I will agree on that …
>

Yes.

Lee

> Thanks!
>
>
> Regards,
>
> Jordi
>
> *De: *v6ops <[e-mail]> en nombre de Lee Howard 
> <lee@asgard..org>
> *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]<mailto:[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.
>
>
>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops