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

Hi Fred, et al.

Speaking as an Operator who is currently validating MAP-T as a
solution, I'm in favour of making sure it itself is included in future
versions of this draft.

There are multiple vendors offering MAP-T Border Relays, and we've
been testing both OpenWRT-based CPEs as well as a custom CPE based on
the Broadcom BCM63138 SoC.
The Broadcom reference SDK comes with the CERNET kernel module and
userland tool, and supports hardware acceleration of MAP-T translated
flows with Broadcom's Runner fastpath.

I was also quite impressed with OpenWRT's implementation; aside from
initially needing internet connectivity to install the map-t module
after a fresh install, no further configuration is required to have
the CPE dynamically configure itself with MAP-T, given the appropriate
DHCPv6 options.  Kudos to the OpenWRT/LEDE devs on their support.

Re: the draft's §5.3.4.  It's succinct enough, whilst still directing
implementors to the relevant RFCs, however I'm still mulling over the
NAT44 and iptables/netfilter concerns that I raised in softwires a few
months back.[1]   The address-sharing mode's algorithm for port
allocations, isn't easily implementable with the current
iptables/netfilter behaviour.  OpenWRT's approach creates rule
shadowing and port ranges that never get utilised.

-Richard

[1] https://www.ietf.org/mail-archive/web/softwires/current/msg06832.html

On 15 April 2018 at 06:00, Fred Baker <fredbaker.ietf@gmail.com> 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
>