# IPv6 Operations (v6ops) - IETF 115 London   {#ipv6-operations-v6ops---ietf-115-london}

Date and Time: 11/11/2022 Friday 9:30-11:30 GMT  
Location: London, Hilton London Metropole, Kensington 2  
Chairs: Ron Bonica, Xipeng Xiao  
AD: Warren Kumari  
Minute takers: Ryo Yanagida, Momoka Yamamoto, Giuseppe Fioccola, Nick
Buraglio  
Session recording:
https://play.conf.meetecho.com/Playout/?session=IETF115-V6OPS-20221111-0930

Zulip Stream: https://zulip.ietf.org/login/#narrow/stream/v6ops

## Chairs   {#chairs}

*   The chair Xipeng Xiao presented the WG status
    (https://datatracker.ietf.org/meeting/115/materials/slides-115-v6ops-00-note-well-and-wg-status).
    It was highlighted that one of the goal is to solve IPv6 challenges
    *   There is already some effort: the IPv6 book from Brian Carpenter
        and the side meeting on IPv6 enterprise issues

*   Call for participation/contribution
*   Let the chairs know if you can think of anything else that's
    meaningful for WG to do

## Administrative   {#administrative}

The AD Warren Kumari suggested to take a 2-min of silence for the
Remembrance Day

## WG Draft   {#wg-draft}

### [Selectively Applying Host Isolation to Simplify IPv6 First-hop Deployment --- XiPeng Xiao][1]   {#selectively-applying-host-isolation-to-simplify-ipv6-first-hop-deployment--xipeng-xiao}

*   **Xipeng Xiao** presented
    (https://datatracker.ietf.org/meeting/115/materials/slides-115-v6ops-01).The
    draft has 3 parts: summary of known issues, summary of optimization
    solutions and how to apply host isolation to avoid potential issues.
    *   *No questions/comments*

## Individual Drafts   {#individual-drafts}

### [Framework of Multi-domain IPv6-only Underlay Networks and IPv4 as a Service --- Chongfeng Xie][2]   {#framework-of-multi-domain-ipv6-only-underlay-networks-and-ipv4-as-a-service--chongfeng-xie}

*   **Chongfeng Xie** presented
    (https://datatracker.ietf.org/meeting/115/materials/slides-115-v6ops-02-chongfeng-v3-framework-of-multi-domain-ipv6-only).
    The draft aims to provide end-to-end IPv4 service delivery over
    multi-domain IPv6-only underlay networks. The chain of XLAT
    translations imply an excessive number of transition GWs and
    tunnels. The framework intends to setup end-to-end IPv6 tunnel or
    translation-based data-path across domains in a secure and scalable
    way. In the solution every PE at network edge has address mapping
    rules to provide IPv4/IPv6 prefix mapping. Those rules provide
    reachability information of IPv4 prefixes across an IPv6-only
    domain. Field trial in production network was also presented.
    
    *   Zhenbin Li: I think this draft provide a solution to a problem
        that has needed a solution for a long time. It is related to
        control plane as well as data plane issues that would make this
        more complete.
    *   Xing Li: this solution for prefixes adopted in China Telecom to
        pass transition information across domains. Similar to previous
        discussion for users, this time it is for the peers.

### [Deep Dive into IPv6 Extension Header Testing, Nalini Elkins][3]   {#deep-dive-into-ipv6-extension-header-testing-nalini-elkins}

*   **Nalini Elkins** presented
    (https://datatracker.ietf.org/meeting/115/materials/slides-115-v6ops-03-draft-elkins-fw).
    The problem is that studies claim huge packet drops with IPv6 EHs on
    the internet. When tested with PDM EH on standalone servers across
    multiple sites they worked. The scope is to come up with a
    methodology to test EHs behavior. The idea is to deploy servers
    across continents, servers are patched with the kernel. They send
    large FTP with some packets with EH. The next task is to develop a
    clear testing methodology for various topologies. For some CDN IPv6
    is disabled, so EHs are not supported. 3 topologies can be
    considered. The next draft talks of the simplest: client – internet
    – server. In most cases, the topology is client, internet, CDN cache
    server, server (origin server). Another topology is client,
    internet, cloud provider edge (FW/server/etc), cloud-based server.
    The plan is to work on 3 drafts dealing with the topologies. The
    scope is to solve the problem at the IETF.
    *   Jen Linkova: how is the troubleshooting with EH header drop, any
        different from any other causes of packet drop? Why do we need
        to focus on EH packet drop instead of general guidance of
        general packet drop troubleshooting?
    *   Nalini Elkins: it is an interesting question. Sometimes it is
        just IPv6 being dropped; this requires a specific method as EH
        packet drop needs specific sets of testing to actually identify
        how, why and which type of EH is dropped. We have implemented
        our stack in eBPF to send packets with different sizes and
        kinds.
    *   Jen Linkova: I see value because it drives people in sending EHs
        not by change or randomly.
    *   Suresh Krishnan: It can be possible to compare 2 tests in
        parallel (with EH and without EH) and then note the difference.
    *   Nalini Elkins: this is what it is in the draft and what we did.
        The next step is to do test without EH, then repeat with EH.
    *   Gorry Fairhurst: What is the scope? Is this a guide for the
        operator? Is this for end-host? Is this for 6man?
    *   Nalini Elkins: There are different points of view. If I am a
        designer of a protocol and want to use a particular EH, what
        should be done. Then I am user of a protocol, again what should
        I do. If I am a router vendor, what should it be done. We may
        publish a BCP to say what EHs can be used, what can be in clear
        or encrypted, what stay in limited domain or on the Internet.
    *   Gorry Fairhurst: we have to separate. We need to say operators
        what to do. But, eventually, the protocol recommendations would
        go in 6man (e.g. what to encrypt). We have to split apart the
        operational considerations with the protocol implementations.
    *   Nalini Elkins: Agreed. Please get in touch.

### [Deep Dive into IPv6 Extension Header Testing: Standalone Client / Server, Nalini Elkins][4]   {#deep-dive-into-ipv6-extension-header-testing-standalone-client--server-nalini-elkins}

*   **Nalini Elkins** presented
    (https://datatracker.ietf.org/meeting/115/materials/slides-115-v6ops-04-draft-elkins-cs).
    It is analyzed the first topology: client, internet, server. The
    draft describes the methodology of testing with real data and the
    diagnostic methodology utilizing eBPF. The testing is done by
    enabling and sending EH with application data, avoiding DDoS because
    of the sending rate. A test server enabled to send EH in every
    packet to an IPv6 enabled web server and packet capture tools are
    needed on each side. Initial test with CURL. It starts to send first
    without EHs, then send with EHs. Finally it run packet diagnosis.
    Next steps: more discussion on crafted packets, troubleshooting if
    problems arise, refer to upcoming drafts.
    *   Antoine Fressancourt: You mentioned you'd send TCP syn, in your
        testing, are you also planning to look at ack as well? If you
        keep sending TCP syn, you'd be blocked to prevent syn flooding.
    *   Nalini Elkins: That's right, we like to use an actual
        application. Let me think of a way to craft a right packet.
    *   Antoine Fressancourt: This is why it is better to go with
        applications packet with EHs. Maybe inject an EH in the kernel?
    *   Nalini Elkins: Let's discuss offline.
    *   Aleksandr Klimenko: do you see packet drops due to MTU?
    *   Nalini Elkins: tons of fragmentation, but no loss due to MTU
        issues. MTU drops concerned me, not there yet. In base testing
        not seen too many.
    *   Ana Custura: We have a tool called pathspider that can be used
        to craft whatever packets you like.
    *   Nalini Elkins: Let's talk offline and see if we can utilise your
        tool to craft packets. We focused on real application so far but
        it would be good to collaborate. Let's work together.

### [Scalability of IPv6 Transition Technologies for IPv4aaS, Gabor Lencse][5]   {#scalability-of-ipv6-transition-technologies-for-ipv4aas-gabor-lencse}

*   **Gabor Lencse** presented
    (https://datatracker.ietf.org/meeting/115/materials/slides-115-v6ops-05-draft-lencse).
    The scalability test results of IPv6 transition technologies for
    IPv4aaS were showed. This is useful for operators to find the right
    technology for their network. New results: scalability comparison of
    Jool of 464XLATand MAP-T. Testing method: CE and PE benchmarked
    together. Measurement setup is shown (same for both). Scalability of
    464XLAT and MAP-T is shown against the number of CPU cores. MAP-T
    shows better scale increasing the number of cores.
    *   Eric Vincke: do you use the same UDP ports? Do the queries come
        from the same ports?
    *   Gabor Lencse: We use different source ports. Up-to 100 different
        source ports. MAP-T limit is at 2000.
    *   Eric Vincke: ok because I expect impact on performance if you
        use many different ports. Did the number of different source
        port impact the performance?
    *   Gabor Lencse: it is the case. If you use more source ports, you
        exhaust resources. There is a limitation for MAP-T.
    *   Nick Buraglio: when working on IPv6-only, the question I often
        receive is about performance. So, thank you for testing and
        sharing results.
    *   Gabor Lencse: Thank you for the comment/feedback. We plan to do
        more tests on this in the future.

### [IPv6 only iterative resolver utilising NAT64, Momoka Yamamoto][6]   {#ipv6-only-iterative-resolver-utilising-nat64-momoka-yamamoto}

*   **Momoka Yamamoto** presented
    (https://datatracker.ietf.org/meeting/115/materials/slides-115-v6ops-06-draft-momoka).
    The motivation for this draft is that IPv6-only resolvers are
    unusable because of IPv4 authoritative resolvers. All other
    applications use DNS64 but a resolver can’t because it is the
    resolver. IPv6-only resolvers cannot resolve all zones. Following
    BCP91, an IPv6-only resolver can do the IPv4 to IPv6 translation
    inside the iterative resolver and make it “dual-stack”. Solution is
    discussed. Most apps reach IPv4 via DNS64/NAT64, but CLAT cannot be
    used by the resolvers. Implementations: not yet merged but DNS
    implementing this.
    *   Ryo Yanagida: DNS has been tricky to support in IPv6-only
        environment. I think this draft should go ahead as
        informational.
    *   Mark Andrews: If we are moving to IPv6-only, we need to figure
        out how to support IPv4. We have a way to sort this by using
        IPv4 as a Service, so DNS64 is already used. We need to stop
        doing more more fixes to DNS64. It was promised to be a
        short-lived solution but it is now around for 10 years.
    *   Momoka Yamamoto: I can't object your comment but as an user of
        these mechanisms, NAT64/DNS64 is the easier option. This is not
        to force people, it is purely informational.
    *   David Lampaert: to reply to Mark Andrews, this has no specific
        DNS64 dependency. It helps to achieve IPv6-only in domains with
        IPv4-only authoritative resolvers.
    *   Mark Andrews: if there is a proper implementation of
        DS-lite/XLAT/MAP-T, you do not need this.
    *   David Lamparter: I may not want any of this.
    *   Mark Andrews: You have to begin with IPv4 as a service. These
        mechanisms require NAT64.
    *   Lorenzo Colitti: I agree with David Lampaert. DNS64 is very
        easy. Deploying IPv4 as a service is tricky. This eliminates the
        need of looking after the IPv4 infrastructure rather than just
        looking after an IPv6 network with NAT64 and DNS64. Solution is
        easy and not harmful.
    *   Xipeng Xiao: We stop here and move on.

**Xipeng Xiao**: It's 11, we'll take a 2-min of silence.

### [Minimizing Damage of Limiting Number of IPv6 Addresses per Host, Jen Linkova][7]   {#minimizing-damage-of-limiting-number-of-ipv6-addresses-per-host-jen-linkova}

*   **Jen Linkova** presented
    (https://datatracker.ietf.org/meeting/115/materials/slides-115-v6ops-07-minimizing-damage-of-limiting-number-of-ipv6-addresses-per-host).
    We need multiple addresses for any ordinary host. For example,
    single prefix network needs 4, two-prefixes needs 7. ChromeOs needs
    7-9. RFC 7934 also suggests to use multiple addresses. In reality
    wireless APs and switches have hardcoded low limits on the number of
    IPv6 addresses/MAC. No indication that limit is reached. When
    reached there is an unpredictable behavior. The tactical fix is in
    draft-linkova-v6ops-ipmaclimit. Long-term fix is to reserve /64 per
    host.
    *   Suresh Krishnan: it is a valid problem. Maybe there are other
        mechanisms to be discussed off-line. Need a protocol mechanism
        for signaling sin I do not like silent failure.
    *   Jen Linkova: no reason to send an alarm if it is not actionable.
    *   Suresh Krishnan: 3GPP already does it, give /64 to any host.
    *   Warren Kumari: If the hardware can't support (e.g. small router
        at home), is it still compliant with your draft?
    *   Jen Linkova: let’s say SHOULD instead of MUST in the draft.
    *   Eric Vincke: there are side-effects with many IP per MAC in
        particular for multicast. Using multiple IPv6 addresses is for
        privacy, using a single /64 per host will eliminate this privacy
        effect. Is it the AP that poses the limit? Or is it the router
        that poses the limit?
    *   Jen Linkova: no, how can you know?
    *   Eric Vincke: you can guess. You lose privacy
    *   Jen Linkova: It is not static. I'll just give you a different
        /64.
    *   Eric Vincke: You know that DHCPv6 is stateful right?
    *   Lorenzo Colitti: it is difficult to say, but improves what we
        have today with IPv6. One thing that is not on the draft is that
        perhaps this could be used to pass /64 to a laptop and let it
        have a bunch of docker containers.

## Operational Presentation   {#operational-presentation}

### Mythic Beasts' IPv6-only Hosting ¨C Progress since 2018 --- Peter Stevens   {#mythic-beasts-ipv6-only-hosting-c-progress-since-2018--peter-stevens}

*   **Peter Stevens** presented
    (https://datatracker.ietf.org/meeting/115/materials/slides-115-v6ops-08-mythic-beasts-ipv6-only-hosting).
    Regarding Virtual servers, our VMs talk IPv4 orIPv6: IPv4 allocated
    statically via DHCP and IPv6 allocated statically via /64 per
    customer. DS is rubbish, IPv6-only is cheaper as we charge for IPv4
    addresses. What does not work: email, FTP, Hadoop. What doesn’t work
    well: docker, snap, node.js, many Apps still prefer IPv4 so switch
    it off. Discussion of issues, solutions and current status. Retiring
    legacy things is hard. Operational aspects discussed, in particular
    on the use of Raspberry Pi computers, how to put them in shelfs to
    build distributed Apps.
    
    *   David Somers-Harris: Are you running a BGP service?
    *   Peter Stevens: We are running BGP on every switch
    *   Lorenzo Colitti: Can you do SLAAC with EUI64?
    *   Peter Stevens: Not fully sure if you can do full PXE-boot w/
        SLAAC
    *   Lorenzo Colitti: Tried sending RA from Raspberry Pi with NAT64
        options but did not fully work.
    *   Ana Custura: You mentioned Clatd; I may be able to get you in
        touch with someone who could package it.
    *   Peter Stevens: It would be great if it can be a debian package
        and have it in our package repository.



[1]: https://datatracker.ietf.org/doc/draft-ietf-v6ops-nd-considerations/
[2]: https://datatracker.ietf.org/doc/draft-xie-v6ops-framework-md-ipv6only-underlay/
[3]: https://datatracker.ietf.org/doc/draft-elkins-v6ops-eh-deepdive-fw/
[4]: https://datatracker.ietf.org/doc/draft-elkins-v6ops-eh-deepdive-cs/
[5]: https://datatracker.ietf.org/doc/draft-lencse-v6ops-transition-scalability/
[6]: https://datatracker.ietf.org/doc/draft-momoka-v6ops-ipv6-only-resolver/
[7]: https://www.ietf.org/archive/id/draft-linkova-v6ops-ipmaclimi-00.html