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
Administrative
The AD Warren Kumari suggested to take a 2-min of silence for the
Remembrance Day
WG Draft
Individual Drafts
- 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.
- 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.
- 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.
- 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.
- 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.