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

• 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

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

WG Draft

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

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

• 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

• 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

• 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

• 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

• 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

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.