SlideShare ist ein Scribd-Unternehmen logo
1 von 33
Downloaden Sie, um offline zu lesen
IPv6 Operational Issues
(with DNS)
Geoff Huston
IETF Best Current Practice –
BCP 91
RFC3901 – September 2004 “DNS IPv6 Transport Operational Guidelines”:
• Every recursive name server SHOULD be either IPv4-only or dual stack
• Every DNS zone SHOULD be served by at least one IPv4-reachable name server
IETF Best Current Practice –
BCP 91
RFC3901 – September 2004 “DNS IPv6 Transport Operational Guidelines”:
• Every recursive name server SHOULD be either IPv4-only or dual stack
• Every DNS zone SHOULD be served by at least one IPv4-reachable name server
Which is saying as an IPv6 Operational guideline “you better keep IPv4 going”
The RFC actually says very little about IPv6!
Proposed: 3901bis
Current IETF draft proposed to update RFC3901 by saying:
• It is RECOMMENDED that are least two NS for a zone are dual stack name
servers
• Every authoritative DNS zone SHOULD be served by at least one IPv6-
reachable authoritative name server
Which is saying as an IPv6 Operational guideline “time to take IPv6 seriously” and NOT saying
that servers need to keep IPv4 around– which is largely the opposite of the advice in RFC
3901!
The assumption behind 3901bis
• That IPv6 is now a mature and well understood technology, and using
IPv6 as the transport for the DNS is as efficient and as fast as using
IPv4
The assumption behind 3901bis
• That IPv6 is now a mature and well understood technology, and using
IPv6 as the transport for the DNS is as efficient and as fast as using
IPv4
Is this really true?
IPv6 and the DNS
How well is IPv6 supported in the DNS?
1. How does the DNS handle dual-stacked authoritative servers?
• Is there a “happy eyeballs” version of DNS server selection?
• Or is there a reverse bias to use IPv4?
2. If you placed authoritative servers on an IPv6-only service how
many users would be able to reach you?
3. And what about DNSSEC?
• How well does IPv6 support large UDP packets?
Dual Stack and the DNS
A “happy eyeballs*” DNS approach would be
to prefer to use the IPv6 address of the
authoritative server in preference to the IPv4
address
A “reverse bias” DNS approach would be to
prefer to use the IPv4 address
Data collected Dec 23 – Jan 24 using 445M
individual measurements
IPv4 Only
43%
IPv6 Only
11%
IPv4 + IPv6
46%
% of user measurements
Dual Stack and the DNS
A “happy eyeballs*” DNS approach would be
to prefer to use the IPv6 address of the
authoritative server in preference to the IPv4
address
A “reverse bias” DNS approach would be to
prefer to use the IPv4 address
Data collected Dec 23 – Jan 24 using 445M
individual measurements
IPv4 Only
43%
IPv6 Only
11%
IPv4 + IPv6
46%
% of user measurements
Less than one half of all name
resolution query sequences show both
protocols being used to query a name
at the authoritative server
Dual Stack DNS
A “happy eyeballs” DNS approach
would be to prefer to use the IPv6
address of the authoritative server in
preference to the IPv4 address and
follow this initial query with a IPv4
query soon after
We just don’t observe a visible bias to
this “IPv6 First” approach
0%
5%
10%
15%
20%
25%
30%
35%
40%
45%
V6-V4 V4-V6 V6-V6 V4-V4
First 2 Queries
Happy Eyeballs?
V4 Only
V6 Only
V4-V6
V6-V4
Dual Stack DNS
A “happy eyeballs” DNS approach
would be minimise the delay between
the initial 2 queries
Which is observed in the data, but we
also see evidence of conventional DNS
timeout values of 370ms, 400ms,
800ms and 1 sec
Is the high repeat query count in the
first 50 ms due to DNSMASQ
behaviour?
Delay between first 2 Queries
Dual Stack DNS
How well is IPv6 supported in the DNS?
1. How does the DNS handle dual-stacked authoritative servers?
• Is there a “happy eyeballs” version of DNS server selection?
• Or is there a reverse bias to use IPv4?
2. If you placed authoritative servers on an IPv6-only service how
many users would be able to reach you?
3. And what about DNSSEC?
• How well does IPv6 support large UDP packets?
No!
Probably!
Dual Stack DNS
How well is IPv6 supported in the DNS?
1. How does the DNS handle dual-stacked authoritative servers?
• Is there a “happy eyeballs” version of DNS server selection?
• Or is there a reverse bias to use IPv4?
2. If you placed authoritative servers on an IPv6-only service how
many users would be able to reach you?
3. And what about DNSSEC?
• How well does IPv6 support large UDP packets?
No!
Probably!
Dual Stack vs IPv6 only DNS
No query – 35%
IPv6 – 65%
IPv6 Only Test
In this case the authoritative name server only
has an IPv6 address
Of all the clients that are presented with an
experiment (51M over 5 days) 65% of names
are seen asking for the experiment name if the
DNS server is reachable over IPv6 only
No query – 35%
IPv6 – 65%
Dual Stack vs IPv6 only DNS
IPv6 Only Test
Dual Stack
IPv4 Only
43%
IPv6 Only
11%
IPv4 + IPv6
46%
Dual Stack DNS
How well is IPv6 supported in the DNS?
1. How does the DNS handle dual-stacked authoritative servers?
• Is there a “happy eyeballs” version of DNS server selection?
• Or is there a reverse bias to use IPv4?
2. If you placed authoritative servers on an IPv6-only service how
many users would be able to reach you?
3. And what about DNSSEC?
• How well does IPv6 support large UDP packets?
No!
Probably!
Only 65%
Dual Stack DNS
How well is IPv6 supported in the DNS?
1. How does the DNS handle dual-stacked authoritative servers?
• Is there a “happy eyeballs” version of DNS server selection?
• Or is there a reverse bias to use IPv4?
2. If you placed authoritative servers on an IPv6-only service how
many users would be able to reach you?
3. And what about DNSSEC?
• How well does IPv6 support large UDP packets?
No!
Probably!
Only 55%
Who uses large DNS packets
anyway? .sl 3319
.pl 2193
.gdn 1954
.ve 1951
.uy 1951
.bg 1951
.xn--mgbx4cd0ab 1931
.africa 1897
.ad 1769
.ss 1715
.firmdale 1693
.xn--mgbah1a3hjkrd 1691
.xn--mgbt3dhd 1681
.ar 1675
.nowruz 1669
.beats 1667
.apple 1667
.shia 1665
.pars 1665
.tci 1663
.zm 1661
.td 1661
.si 1661
.na 1661
.ly 1661
.kw 1661
.ke 1661
.gy 1661
.lifestyle 1638
.living 1629
Size of dnssec-signed DNSKEY
response for some gtlds in
Nov-23
These folk do!
Who uses large DNS packets
anyway?
Some 300 gtlds
rely on
fragmented
UDP responses!
Is this a problem for today’s
IPv6 Internet?
• Can we measure the extent to which users might be affected with this
scenario of large DNS responses, DNS resolvers and IPv6?
Yes!
By sending large (>1500 octet) responses in the DNS and obeying the query’s
EDNS buffer size and fragmenting or truncating as determined by the query
V6, the DNS and Fragmented UDP
Total number of tests (DNS over UDP over IPv6): 32,951,595
Failure Rate in receiving a large response: 18,557,838
IPv6 Fragmentation Failure Rate: 56%
Data gathered 20 Dec 2023 – 9 Jan 2024
V6, the DNS and Fragmented UDP
Total number of tests (DNS over UDP over IPv6): 32,951,595
Failure Rate in receiving a large response: 18,557,838
IPv6 Fragmentation Failure Rate: 56%
Data gathered 20 Dec 2023 – 9 Jan 2024
That’s awesomely bad!
Dual Stack DNS
How well is IPv6 supported in the DNS?
1. How does the DNS handle dual-stacked authoritative servers?
• Is there a “happy eyeballs” version of DNS server selection?
• Or is there a reverse bias to use IPv4?
2. If you placed authoritative servers on an IPv6-only service how
many users would be able to reach you?
3. And what about DNSSEC?
• How well does IPv6 support large UDP packets?
No!
Probably!
Only 55%
Very Badly!
What should we do about this?
What can we do about it?
Fix it!
Get all the deployed routers, switches and firewalls and related
network middleware to accept packets with IPv6 Fragmentation
Headers
What can we do about it?
Change it!
Change application behaviour to avoid the use of packet
fragmentation completely
What do the RFC’s say?
What do the RFC’s say?
What do the RFC’s say?
What do the RFC’s say?
This BCP is saying that using EDNS(0) in the
DNS to signal the capability of accepting large
fragmented DNS responses was unwise, and if a
host/application does not know the path MTU, it
should truncate at UDP at 1280 octets
DON’T FRAGMENT!
Truncate and failover to TCP
• Use an EDNS Buffer Size in queries to ensure that IPv6 responses are
never fragmented
• Large responses will be truncated
• The truncation should trigger the querier to perform an immediate
followup of the same query, using TCP
• Which means that we are probably looking at working around the
problem by changing the configuration of DNS queries and use an
EDNS buffer size of 1232 octets
See https://dnsflagday.net/2020/
Is the DNS ready for IPv6-
only?
Not yet!
Thanks!

Weitere ähnliche Inhalte

Ähnlich wie IPv6 Operational Issues (with DNS), presented by Geoff Huston at IETF 119

Understanding i pv6 2
Understanding i pv6 2Understanding i pv6 2
Understanding i pv6 2
srmanjuskp
 

Ähnlich wie IPv6 Operational Issues (with DNS), presented by Geoff Huston at IETF 119 (20)

bdNOG 7 - Re-engineering the DNS - one resolver at a time
bdNOG 7 - Re-engineering the DNS - one resolver at a timebdNOG 7 - Re-engineering the DNS - one resolver at a time
bdNOG 7 - Re-engineering the DNS - one resolver at a time
 
Testing Rolling Roots
Testing Rolling RootsTesting Rolling Roots
Testing Rolling Roots
 
Ventajas de IPv6
Ventajas de IPv6Ventajas de IPv6
Ventajas de IPv6
 
Re-Engineering the DNS – One Resolver at a Time
Re-Engineering the DNS – One Resolver at a Time Re-Engineering the DNS – One Resolver at a Time
Re-Engineering the DNS – One Resolver at a Time
 
IETF 113: IPv6 fragmentation and EH behaviours
IETF 113: IPv6 fragmentation and EH behavioursIETF 113: IPv6 fragmentation and EH behaviours
IETF 113: IPv6 fragmentation and EH behaviours
 
Understanding i pv6 2
Understanding i pv6 2Understanding i pv6 2
Understanding i pv6 2
 
NANOG 82: DNS Evolution
NANOG 82: DNS EvolutionNANOG 82: DNS Evolution
NANOG 82: DNS Evolution
 
Is IPv6 Security Still an Afterthought?
Is IPv6 Security Still an Afterthought?Is IPv6 Security Still an Afterthought?
Is IPv6 Security Still an Afterthought?
 
Life Without IPv4: Tore Anderson, IPv6 guru, Redpill Linpro
Life Without IPv4: Tore Anderson, IPv6 guru, Redpill LinproLife Without IPv4: Tore Anderson, IPv6 guru, Redpill Linpro
Life Without IPv4: Tore Anderson, IPv6 guru, Redpill Linpro
 
Internet Week 2018: 1.1.1.0/24 A report from the (anycast) trenches
Internet Week 2018: 1.1.1.0/24 A report from the (anycast) trenchesInternet Week 2018: 1.1.1.0/24 A report from the (anycast) trenches
Internet Week 2018: 1.1.1.0/24 A report from the (anycast) trenches
 
btNOG 8: IP technology adoption in Bhutan
btNOG 8: IP technology adoption in Bhutan btNOG 8: IP technology adoption in Bhutan
btNOG 8: IP technology adoption in Bhutan
 
APNIC Update
APNIC Update APNIC Update
APNIC Update
 
Measuring IPv6 Performance, RIPE73
Measuring IPv6 Performance, RIPE73Measuring IPv6 Performance, RIPE73
Measuring IPv6 Performance, RIPE73
 
OpenDNS Whitepaper: Platform Technology
OpenDNS Whitepaper: Platform TechnologyOpenDNS Whitepaper: Platform Technology
OpenDNS Whitepaper: Platform Technology
 
CAv6TF Meeting - 2014-05-27 - IPv6@ VMware Integration Engineering
CAv6TF Meeting - 2014-05-27 - IPv6@ VMware Integration EngineeringCAv6TF Meeting - 2014-05-27 - IPv6@ VMware Integration Engineering
CAv6TF Meeting - 2014-05-27 - IPv6@ VMware Integration Engineering
 
3hows
3hows3hows
3hows
 
Presentation on 'The Path to Resolverless DNS' by Geoff Huston
Presentation on 'The Path to Resolverless DNS'  by Geoff HustonPresentation on 'The Path to Resolverless DNS'  by Geoff Huston
Presentation on 'The Path to Resolverless DNS' by Geoff Huston
 
HKNOG 1.0 - DDoS attacks in an IPv6 World
HKNOG 1.0 -  DDoS attacks in an IPv6 WorldHKNOG 1.0 -  DDoS attacks in an IPv6 World
HKNOG 1.0 - DDoS attacks in an IPv6 World
 
mnNOG 3: IP technology adoption in Mongolia
mnNOG 3: IP technology adoption in MongoliamnNOG 3: IP technology adoption in Mongolia
mnNOG 3: IP technology adoption in Mongolia
 
npNOG 2: APNIC IPv6 deployment
npNOG 2: APNIC IPv6 deploymentnpNOG 2: APNIC IPv6 deployment
npNOG 2: APNIC IPv6 deployment
 

Mehr von APNIC

Mehr von APNIC (20)

APNIC Updates presented by Paul Wilson at ARIN 53
APNIC Updates presented by Paul Wilson at ARIN 53APNIC Updates presented by Paul Wilson at ARIN 53
APNIC Updates presented by Paul Wilson at ARIN 53
 
DDoS In Oceania and the Pacific, presented by Dave Phelan at NZNOG 2024
DDoS In Oceania and the Pacific, presented by Dave Phelan at NZNOG 2024DDoS In Oceania and the Pacific, presented by Dave Phelan at NZNOG 2024
DDoS In Oceania and the Pacific, presented by Dave Phelan at NZNOG 2024
 
'Future Evolution of the Internet' delivered by Geoff Huston at Everything Op...
'Future Evolution of the Internet' delivered by Geoff Huston at Everything Op...'Future Evolution of the Internet' delivered by Geoff Huston at Everything Op...
'Future Evolution of the Internet' delivered by Geoff Huston at Everything Op...
 
On Starlink, presented by Geoff Huston at NZNOG 2024
On Starlink, presented by Geoff Huston at NZNOG 2024On Starlink, presented by Geoff Huston at NZNOG 2024
On Starlink, presented by Geoff Huston at NZNOG 2024
 
Networking in the Penumbra presented by Geoff Huston at NZNOG
Networking in the Penumbra presented by Geoff Huston at NZNOGNetworking in the Penumbra presented by Geoff Huston at NZNOG
Networking in the Penumbra presented by Geoff Huston at NZNOG
 
IP addressing and IPv6, presented by Paul Wilson at IETF 119
IP addressing and IPv6, presented by Paul Wilson at IETF 119IP addressing and IPv6, presented by Paul Wilson at IETF 119
IP addressing and IPv6, presented by Paul Wilson at IETF 119
 
draft-harrison-sidrops-manifest-number-01, presented at IETF 119
draft-harrison-sidrops-manifest-number-01, presented at IETF 119draft-harrison-sidrops-manifest-number-01, presented at IETF 119
draft-harrison-sidrops-manifest-number-01, presented at IETF 119
 
Making an RFC in Today's IETF, presented by Geoff Huston at IETF 119
Making an RFC in Today's IETF, presented by Geoff Huston at IETF 119Making an RFC in Today's IETF, presented by Geoff Huston at IETF 119
Making an RFC in Today's IETF, presented by Geoff Huston at IETF 119
 
Benefits of doing Internet peering and running an Internet Exchange (IX) pres...
Benefits of doing Internet peering and running an Internet Exchange (IX) pres...Benefits of doing Internet peering and running an Internet Exchange (IX) pres...
Benefits of doing Internet peering and running an Internet Exchange (IX) pres...
 
APNIC Update and RIR Policies for ccTLDs, presented at APTLD 85
APNIC Update and RIR Policies for ccTLDs, presented at APTLD 85APNIC Update and RIR Policies for ccTLDs, presented at APTLD 85
APNIC Update and RIR Policies for ccTLDs, presented at APTLD 85
 
NANOG 90: 'BGP in 2023' presented by Geoff Huston
NANOG 90: 'BGP in 2023' presented by Geoff HustonNANOG 90: 'BGP in 2023' presented by Geoff Huston
NANOG 90: 'BGP in 2023' presented by Geoff Huston
 
APAN 57: APNIC Report at APAN 57, Bangkok, Thailand
APAN 57: APNIC Report at APAN 57, Bangkok, ThailandAPAN 57: APNIC Report at APAN 57, Bangkok, Thailand
APAN 57: APNIC Report at APAN 57, Bangkok, Thailand
 
Lao Digital Week 2024: It's time to deploy IPv6
Lao Digital Week 2024: It's time to deploy IPv6Lao Digital Week 2024: It's time to deploy IPv6
Lao Digital Week 2024: It's time to deploy IPv6
 
AINTEC 2023: Networking in the Penumbra!
AINTEC 2023: Networking in the Penumbra!AINTEC 2023: Networking in the Penumbra!
AINTEC 2023: Networking in the Penumbra!
 
CNIRC 2023: Global and Regional IPv6 Deployment 2023
CNIRC 2023: Global and Regional IPv6 Deployment 2023CNIRC 2023: Global and Regional IPv6 Deployment 2023
CNIRC 2023: Global and Regional IPv6 Deployment 2023
 
AFSIG 2023: APNIC Foundation and support for Internet development
AFSIG 2023: APNIC Foundation and support for Internet developmentAFSIG 2023: APNIC Foundation and support for Internet development
AFSIG 2023: APNIC Foundation and support for Internet development
 
AFNOG 1: Afghanistan IP Deployment Status
AFNOG 1: Afghanistan IP Deployment StatusAFNOG 1: Afghanistan IP Deployment Status
AFNOG 1: Afghanistan IP Deployment Status
 
AFSIG 2023: Internet routing and addressing
AFSIG 2023: Internet routing and addressingAFSIG 2023: Internet routing and addressing
AFSIG 2023: Internet routing and addressing
 
AFSIG 2023: APNIC - Registry & Development
AFSIG 2023: APNIC - Registry & DevelopmentAFSIG 2023: APNIC - Registry & Development
AFSIG 2023: APNIC - Registry & Development
 
Afghanistan IGF 2023: The ABCs and importance of cybersecurity
Afghanistan IGF 2023: The ABCs and importance of cybersecurityAfghanistan IGF 2023: The ABCs and importance of cybersecurity
Afghanistan IGF 2023: The ABCs and importance of cybersecurity
 

Kürzlich hochgeladen

Call Girls In Defence Colony Delhi 💯Call Us 🔝8264348440🔝
Call Girls In Defence Colony Delhi 💯Call Us 🔝8264348440🔝Call Girls In Defence Colony Delhi 💯Call Us 🔝8264348440🔝
Call Girls In Defence Colony Delhi 💯Call Us 🔝8264348440🔝
soniya singh
 
Dwarka Sector 26 Call Girls | Delhi | 9999965857 🫦 Vanshika Verma More Our Se...
Dwarka Sector 26 Call Girls | Delhi | 9999965857 🫦 Vanshika Verma More Our Se...Dwarka Sector 26 Call Girls | Delhi | 9999965857 🫦 Vanshika Verma More Our Se...
Dwarka Sector 26 Call Girls | Delhi | 9999965857 🫦 Vanshika Verma More Our Se...
Call Girls In Delhi Whatsup 9873940964 Enjoy Unlimited Pleasure
 
Hot Service (+9316020077 ) Goa Call Girls Real Photos and Genuine Service
Hot Service (+9316020077 ) Goa  Call Girls Real Photos and Genuine ServiceHot Service (+9316020077 ) Goa  Call Girls Real Photos and Genuine Service
Hot Service (+9316020077 ) Goa Call Girls Real Photos and Genuine Service
sexy call girls service in goa
 
Call Girls In Pratap Nagar Delhi 💯Call Us 🔝8264348440🔝
Call Girls In Pratap Nagar Delhi 💯Call Us 🔝8264348440🔝Call Girls In Pratap Nagar Delhi 💯Call Us 🔝8264348440🔝
Call Girls In Pratap Nagar Delhi 💯Call Us 🔝8264348440🔝
soniya singh
 
Call Girls In Sukhdev Vihar Delhi 💯Call Us 🔝8264348440🔝
Call Girls In Sukhdev Vihar Delhi 💯Call Us 🔝8264348440🔝Call Girls In Sukhdev Vihar Delhi 💯Call Us 🔝8264348440🔝
Call Girls In Sukhdev Vihar Delhi 💯Call Us 🔝8264348440🔝
soniya singh
 
CALL ON ➥8923113531 🔝Call Girls Lucknow Lucknow best sexual service Online
CALL ON ➥8923113531 🔝Call Girls Lucknow Lucknow best sexual service OnlineCALL ON ➥8923113531 🔝Call Girls Lucknow Lucknow best sexual service Online
CALL ON ➥8923113531 🔝Call Girls Lucknow Lucknow best sexual service Online
anilsa9823
 

Kürzlich hochgeladen (20)

VVVIP Call Girls In Connaught Place ➡️ Delhi ➡️ 9999965857 🚀 No Advance 24HRS...
VVVIP Call Girls In Connaught Place ➡️ Delhi ➡️ 9999965857 🚀 No Advance 24HRS...VVVIP Call Girls In Connaught Place ➡️ Delhi ➡️ 9999965857 🚀 No Advance 24HRS...
VVVIP Call Girls In Connaught Place ➡️ Delhi ➡️ 9999965857 🚀 No Advance 24HRS...
 
VIP 7001035870 Find & Meet Hyderabad Call Girls LB Nagar high-profile Call Girl
VIP 7001035870 Find & Meet Hyderabad Call Girls LB Nagar high-profile Call GirlVIP 7001035870 Find & Meet Hyderabad Call Girls LB Nagar high-profile Call Girl
VIP 7001035870 Find & Meet Hyderabad Call Girls LB Nagar high-profile Call Girl
 
WhatsApp 📞 8448380779 ✅Call Girls In Mamura Sector 66 ( Noida)
WhatsApp 📞 8448380779 ✅Call Girls In Mamura Sector 66 ( Noida)WhatsApp 📞 8448380779 ✅Call Girls In Mamura Sector 66 ( Noida)
WhatsApp 📞 8448380779 ✅Call Girls In Mamura Sector 66 ( Noida)
 
Call Girls In Defence Colony Delhi 💯Call Us 🔝8264348440🔝
Call Girls In Defence Colony Delhi 💯Call Us 🔝8264348440🔝Call Girls In Defence Colony Delhi 💯Call Us 🔝8264348440🔝
Call Girls In Defence Colony Delhi 💯Call Us 🔝8264348440🔝
 
Dwarka Sector 26 Call Girls | Delhi | 9999965857 🫦 Vanshika Verma More Our Se...
Dwarka Sector 26 Call Girls | Delhi | 9999965857 🫦 Vanshika Verma More Our Se...Dwarka Sector 26 Call Girls | Delhi | 9999965857 🫦 Vanshika Verma More Our Se...
Dwarka Sector 26 Call Girls | Delhi | 9999965857 🫦 Vanshika Verma More Our Se...
 
Call Girls Dubai Prolapsed O525547819 Call Girls In Dubai Princes$
Call Girls Dubai Prolapsed O525547819 Call Girls In Dubai Princes$Call Girls Dubai Prolapsed O525547819 Call Girls In Dubai Princes$
Call Girls Dubai Prolapsed O525547819 Call Girls In Dubai Princes$
 
Call Now ☎ 8264348440 !! Call Girls in Green Park Escort Service Delhi N.C.R.
Call Now ☎ 8264348440 !! Call Girls in Green Park Escort Service Delhi N.C.R.Call Now ☎ 8264348440 !! Call Girls in Green Park Escort Service Delhi N.C.R.
Call Now ☎ 8264348440 !! Call Girls in Green Park Escort Service Delhi N.C.R.
 
𓀤Call On 7877925207 𓀤 Ahmedguda Call Girls Hot Model With Sexy Bhabi Ready Fo...
𓀤Call On 7877925207 𓀤 Ahmedguda Call Girls Hot Model With Sexy Bhabi Ready Fo...𓀤Call On 7877925207 𓀤 Ahmedguda Call Girls Hot Model With Sexy Bhabi Ready Fo...
𓀤Call On 7877925207 𓀤 Ahmedguda Call Girls Hot Model With Sexy Bhabi Ready Fo...
 
Hot Service (+9316020077 ) Goa Call Girls Real Photos and Genuine Service
Hot Service (+9316020077 ) Goa  Call Girls Real Photos and Genuine ServiceHot Service (+9316020077 ) Goa  Call Girls Real Photos and Genuine Service
Hot Service (+9316020077 ) Goa Call Girls Real Photos and Genuine Service
 
How is AI changing journalism? (v. April 2024)
How is AI changing journalism? (v. April 2024)How is AI changing journalism? (v. April 2024)
How is AI changing journalism? (v. April 2024)
 
Russian Call girl in Ajman +971563133746 Ajman Call girl Service
Russian Call girl in Ajman +971563133746 Ajman Call girl ServiceRussian Call girl in Ajman +971563133746 Ajman Call girl Service
Russian Call girl in Ajman +971563133746 Ajman Call girl Service
 
All Time Service Available Call Girls Mg Road 👌 ⏭️ 6378878445
All Time Service Available Call Girls Mg Road 👌 ⏭️ 6378878445All Time Service Available Call Girls Mg Road 👌 ⏭️ 6378878445
All Time Service Available Call Girls Mg Road 👌 ⏭️ 6378878445
 
Call Girls In Pratap Nagar Delhi 💯Call Us 🔝8264348440🔝
Call Girls In Pratap Nagar Delhi 💯Call Us 🔝8264348440🔝Call Girls In Pratap Nagar Delhi 💯Call Us 🔝8264348440🔝
Call Girls In Pratap Nagar Delhi 💯Call Us 🔝8264348440🔝
 
Best VIP Call Girls Noida Sector 75 Call Me: 8448380779
Best VIP Call Girls Noida Sector 75 Call Me: 8448380779Best VIP Call Girls Noida Sector 75 Call Me: 8448380779
Best VIP Call Girls Noida Sector 75 Call Me: 8448380779
 
Russian Call Girls in %(+971524965298 )# Call Girls in Dubai
Russian Call Girls in %(+971524965298  )#  Call Girls in DubaiRussian Call Girls in %(+971524965298  )#  Call Girls in Dubai
Russian Call Girls in %(+971524965298 )# Call Girls in Dubai
 
Call Girls In Sukhdev Vihar Delhi 💯Call Us 🔝8264348440🔝
Call Girls In Sukhdev Vihar Delhi 💯Call Us 🔝8264348440🔝Call Girls In Sukhdev Vihar Delhi 💯Call Us 🔝8264348440🔝
Call Girls In Sukhdev Vihar Delhi 💯Call Us 🔝8264348440🔝
 
Call Girls Ludhiana Just Call 98765-12871 Top Class Call Girl Service Available
Call Girls Ludhiana Just Call 98765-12871 Top Class Call Girl Service AvailableCall Girls Ludhiana Just Call 98765-12871 Top Class Call Girl Service Available
Call Girls Ludhiana Just Call 98765-12871 Top Class Call Girl Service Available
 
CALL ON ➥8923113531 🔝Call Girls Lucknow Lucknow best sexual service Online
CALL ON ➥8923113531 🔝Call Girls Lucknow Lucknow best sexual service OnlineCALL ON ➥8923113531 🔝Call Girls Lucknow Lucknow best sexual service Online
CALL ON ➥8923113531 🔝Call Girls Lucknow Lucknow best sexual service Online
 
GDG Cloud Southlake 32: Kyle Hettinger: Demystifying the Dark Web
GDG Cloud Southlake 32: Kyle Hettinger: Demystifying the Dark WebGDG Cloud Southlake 32: Kyle Hettinger: Demystifying the Dark Web
GDG Cloud Southlake 32: Kyle Hettinger: Demystifying the Dark Web
 
VIP Model Call Girls Hadapsar ( Pune ) Call ON 9905417584 Starting High Prof...
VIP Model Call Girls Hadapsar ( Pune ) Call ON 9905417584 Starting  High Prof...VIP Model Call Girls Hadapsar ( Pune ) Call ON 9905417584 Starting  High Prof...
VIP Model Call Girls Hadapsar ( Pune ) Call ON 9905417584 Starting High Prof...
 

IPv6 Operational Issues (with DNS), presented by Geoff Huston at IETF 119

  • 1. IPv6 Operational Issues (with DNS) Geoff Huston
  • 2. IETF Best Current Practice – BCP 91 RFC3901 – September 2004 “DNS IPv6 Transport Operational Guidelines”: • Every recursive name server SHOULD be either IPv4-only or dual stack • Every DNS zone SHOULD be served by at least one IPv4-reachable name server
  • 3. IETF Best Current Practice – BCP 91 RFC3901 – September 2004 “DNS IPv6 Transport Operational Guidelines”: • Every recursive name server SHOULD be either IPv4-only or dual stack • Every DNS zone SHOULD be served by at least one IPv4-reachable name server Which is saying as an IPv6 Operational guideline “you better keep IPv4 going” The RFC actually says very little about IPv6!
  • 4. Proposed: 3901bis Current IETF draft proposed to update RFC3901 by saying: • It is RECOMMENDED that are least two NS for a zone are dual stack name servers • Every authoritative DNS zone SHOULD be served by at least one IPv6- reachable authoritative name server Which is saying as an IPv6 Operational guideline “time to take IPv6 seriously” and NOT saying that servers need to keep IPv4 around– which is largely the opposite of the advice in RFC 3901!
  • 5. The assumption behind 3901bis • That IPv6 is now a mature and well understood technology, and using IPv6 as the transport for the DNS is as efficient and as fast as using IPv4
  • 6. The assumption behind 3901bis • That IPv6 is now a mature and well understood technology, and using IPv6 as the transport for the DNS is as efficient and as fast as using IPv4 Is this really true?
  • 7. IPv6 and the DNS How well is IPv6 supported in the DNS? 1. How does the DNS handle dual-stacked authoritative servers? • Is there a “happy eyeballs” version of DNS server selection? • Or is there a reverse bias to use IPv4? 2. If you placed authoritative servers on an IPv6-only service how many users would be able to reach you? 3. And what about DNSSEC? • How well does IPv6 support large UDP packets?
  • 8. Dual Stack and the DNS A “happy eyeballs*” DNS approach would be to prefer to use the IPv6 address of the authoritative server in preference to the IPv4 address A “reverse bias” DNS approach would be to prefer to use the IPv4 address Data collected Dec 23 – Jan 24 using 445M individual measurements IPv4 Only 43% IPv6 Only 11% IPv4 + IPv6 46% % of user measurements
  • 9. Dual Stack and the DNS A “happy eyeballs*” DNS approach would be to prefer to use the IPv6 address of the authoritative server in preference to the IPv4 address A “reverse bias” DNS approach would be to prefer to use the IPv4 address Data collected Dec 23 – Jan 24 using 445M individual measurements IPv4 Only 43% IPv6 Only 11% IPv4 + IPv6 46% % of user measurements Less than one half of all name resolution query sequences show both protocols being used to query a name at the authoritative server
  • 10. Dual Stack DNS A “happy eyeballs” DNS approach would be to prefer to use the IPv6 address of the authoritative server in preference to the IPv4 address and follow this initial query with a IPv4 query soon after We just don’t observe a visible bias to this “IPv6 First” approach 0% 5% 10% 15% 20% 25% 30% 35% 40% 45% V6-V4 V4-V6 V6-V6 V4-V4 First 2 Queries Happy Eyeballs? V4 Only V6 Only V4-V6 V6-V4
  • 11. Dual Stack DNS A “happy eyeballs” DNS approach would be minimise the delay between the initial 2 queries Which is observed in the data, but we also see evidence of conventional DNS timeout values of 370ms, 400ms, 800ms and 1 sec Is the high repeat query count in the first 50 ms due to DNSMASQ behaviour? Delay between first 2 Queries
  • 12. Dual Stack DNS How well is IPv6 supported in the DNS? 1. How does the DNS handle dual-stacked authoritative servers? • Is there a “happy eyeballs” version of DNS server selection? • Or is there a reverse bias to use IPv4? 2. If you placed authoritative servers on an IPv6-only service how many users would be able to reach you? 3. And what about DNSSEC? • How well does IPv6 support large UDP packets? No! Probably!
  • 13. Dual Stack DNS How well is IPv6 supported in the DNS? 1. How does the DNS handle dual-stacked authoritative servers? • Is there a “happy eyeballs” version of DNS server selection? • Or is there a reverse bias to use IPv4? 2. If you placed authoritative servers on an IPv6-only service how many users would be able to reach you? 3. And what about DNSSEC? • How well does IPv6 support large UDP packets? No! Probably!
  • 14. Dual Stack vs IPv6 only DNS No query – 35% IPv6 – 65% IPv6 Only Test In this case the authoritative name server only has an IPv6 address Of all the clients that are presented with an experiment (51M over 5 days) 65% of names are seen asking for the experiment name if the DNS server is reachable over IPv6 only
  • 15. No query – 35% IPv6 – 65% Dual Stack vs IPv6 only DNS IPv6 Only Test Dual Stack IPv4 Only 43% IPv6 Only 11% IPv4 + IPv6 46%
  • 16. Dual Stack DNS How well is IPv6 supported in the DNS? 1. How does the DNS handle dual-stacked authoritative servers? • Is there a “happy eyeballs” version of DNS server selection? • Or is there a reverse bias to use IPv4? 2. If you placed authoritative servers on an IPv6-only service how many users would be able to reach you? 3. And what about DNSSEC? • How well does IPv6 support large UDP packets? No! Probably! Only 65%
  • 17. Dual Stack DNS How well is IPv6 supported in the DNS? 1. How does the DNS handle dual-stacked authoritative servers? • Is there a “happy eyeballs” version of DNS server selection? • Or is there a reverse bias to use IPv4? 2. If you placed authoritative servers on an IPv6-only service how many users would be able to reach you? 3. And what about DNSSEC? • How well does IPv6 support large UDP packets? No! Probably! Only 55%
  • 18. Who uses large DNS packets anyway? .sl 3319 .pl 2193 .gdn 1954 .ve 1951 .uy 1951 .bg 1951 .xn--mgbx4cd0ab 1931 .africa 1897 .ad 1769 .ss 1715 .firmdale 1693 .xn--mgbah1a3hjkrd 1691 .xn--mgbt3dhd 1681 .ar 1675 .nowruz 1669 .beats 1667 .apple 1667 .shia 1665 .pars 1665 .tci 1663 .zm 1661 .td 1661 .si 1661 .na 1661 .ly 1661 .kw 1661 .ke 1661 .gy 1661 .lifestyle 1638 .living 1629 Size of dnssec-signed DNSKEY response for some gtlds in Nov-23 These folk do!
  • 19. Who uses large DNS packets anyway? Some 300 gtlds rely on fragmented UDP responses!
  • 20. Is this a problem for today’s IPv6 Internet? • Can we measure the extent to which users might be affected with this scenario of large DNS responses, DNS resolvers and IPv6? Yes! By sending large (>1500 octet) responses in the DNS and obeying the query’s EDNS buffer size and fragmenting or truncating as determined by the query
  • 21. V6, the DNS and Fragmented UDP Total number of tests (DNS over UDP over IPv6): 32,951,595 Failure Rate in receiving a large response: 18,557,838 IPv6 Fragmentation Failure Rate: 56% Data gathered 20 Dec 2023 – 9 Jan 2024
  • 22. V6, the DNS and Fragmented UDP Total number of tests (DNS over UDP over IPv6): 32,951,595 Failure Rate in receiving a large response: 18,557,838 IPv6 Fragmentation Failure Rate: 56% Data gathered 20 Dec 2023 – 9 Jan 2024 That’s awesomely bad!
  • 23. Dual Stack DNS How well is IPv6 supported in the DNS? 1. How does the DNS handle dual-stacked authoritative servers? • Is there a “happy eyeballs” version of DNS server selection? • Or is there a reverse bias to use IPv4? 2. If you placed authoritative servers on an IPv6-only service how many users would be able to reach you? 3. And what about DNSSEC? • How well does IPv6 support large UDP packets? No! Probably! Only 55% Very Badly!
  • 24. What should we do about this?
  • 25. What can we do about it? Fix it! Get all the deployed routers, switches and firewalls and related network middleware to accept packets with IPv6 Fragmentation Headers
  • 26. What can we do about it? Change it! Change application behaviour to avoid the use of packet fragmentation completely
  • 27. What do the RFC’s say?
  • 28. What do the RFC’s say?
  • 29. What do the RFC’s say?
  • 30. What do the RFC’s say? This BCP is saying that using EDNS(0) in the DNS to signal the capability of accepting large fragmented DNS responses was unwise, and if a host/application does not know the path MTU, it should truncate at UDP at 1280 octets DON’T FRAGMENT!
  • 31. Truncate and failover to TCP • Use an EDNS Buffer Size in queries to ensure that IPv6 responses are never fragmented • Large responses will be truncated • The truncation should trigger the querier to perform an immediate followup of the same query, using TCP • Which means that we are probably looking at working around the problem by changing the configuration of DNS queries and use an EDNS buffer size of 1232 octets See https://dnsflagday.net/2020/
  • 32. Is the DNS ready for IPv6- only? Not yet!