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

Hi Richard,

Thanks for the input!

Regarding your comment on the NAT44 iptables/netfilter ... Do you think this is something that can be mention/sorted out by some specific text in my ID ?

I'm guessing it will apply to both MAP-T and MAP-E, not sure if in the same way, but we can have some text to at least make sure implementors sort it out, without the need to update the relevant RFCs. Or do you think they should be updated (which open a another can of worms maybe ...).

Regards,
Jordi

-----Mensaje original-----
De: v6ops <v6ops-bounces@ietf.org> en nombre de Richard Patterson <richard@helix.net.nz>
Fecha: martes, 17 de abril de 2018, 21:21
Para: V6 Ops List <v6ops@ietf.org>
Asunto: 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
    >

    _______________________________________________
    v6ops mailing list
    v6ops@ietf.org
    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.