IETF 117 Trip Report

Posted byM Ackermann

INTERNET ENGINEERING TASK FORCE – 117

 A.K.A

IETF  2023-2

 San Francisco, CA

July 23-28,  2023

  

Section #1 : Executive Summary

Section #2 : Pre Conference Information / Activities &Events

Section # 3 : Detailed Breakout Sessions Attended

 

 Report Prepared by: Michael Ackermann – INTC

EXECUTIVE SUMMARY       

This document is a synopsis of the proceedings of the 117th  meeting of the Internet Engineering Task Force (IETF).   The IETF is the guiding technical body for the Internet and the protocols/applications that run upon it (IP, DNS, DHCP, TCP, UDP, FTP, and many others).   Since the Internet and the applications/protocols that run upon it,  are the most critical and most utilized in the world,  it follows that the IETF is one of the most influential and important  organizations in the world, in spite of the fact that most enterprises are relatively unaware of the IETF.   This document is one of many INTC attempts, to bridge that very large gap.    Most of these same protocols also run  on corporate, government and home networks, making IETF and the bridging of this gap,  even more important.   

From an organizational standpoint, in 1993 the IETF changed from an activity supported by the US Federal Government to an independent, international activity associated with the Internet Society (ISOC), which is a US-based 501(c)(3) corporation.   There are currently over 100 Working Groups, which  exist in 7 IETF Areas (https://www.ietf.org/topics/areas/) .

The IETF is  very technical, well organized and extremely result oriented.  An enormous amount of technical  business is conducted in a relatively short amount of time.  The contacts made at IETF are valuable and many of the people involved  are amazing.   It is truly an environment that inspires one to become more knowledgeable, for many reasons. Attending IETF provides  manifold options to do so.   Representation at the 117 meeting, included  905  people participating on site and 675 virtually.  Attendance continues to increase back into pre Covid ranges, in spite of the fact that the city of San Francisco was unfortunately not well received, as a venue.     

The IETF is a 5.5 day conference  with very full agendas, and has many additional optional sessions  on weekends and in the evenings.   Plus, the short lunch breaks are usually filled with other meetings, as are breakfasts and frequently dinners.    

 The “Hackathon” is a hands on technical event that occurs on Friday, Saturday and Sunday, preceding the actual conference.    INTC is usually represented at the Hackathon and the Internet Engineering and Planning Group ( IEPG), both of which occur the weekend prior to the actual IETF conference

 

 

Another great benefit of working closely with Working Groups such as  IPPM, 6MAN, V6OPS and TLS.  These bodies are responsible for standards, design, implementation and operational issues, which are critical to networking and system management areas, that affect all large organizations and many smaller ones as well.   Activities within these working groups can  provide advanced awareness of many related topics & directions, as well as the ability to influence these directions in ways that are conducive to particular industries or even particular enterprises.  In short, being involved at IETF can pay BIG dividends to business!  Perhaps of even greater value is the ability to interface with and maintain contacts with related industry wide experts!   

Highlight areas of focus at this IETF Meeting (IMHO):

  1. New versions of TLS. TLS 1.3 is intended to provide Forward Secrecy (FS) and while it  can provide extended levels of privacy, it will also represent many potential operational challenges for large organizations.   More challenging is that there is talk of deprecating and/or freezing previous versions of TLS such as 1.2, which are very prevalent in most large organizations.     This will cause manifold operation problems that enterprises are not prepared for.   Many applications do not yet support TLS 1.3,  and many platforms, such as visibility engines and IPSs, will have either reduced or eliminated function/value, when processing TLS 1.3 encrypted session data. 
  2. Enterprises are still not deploying IPv6, but several critical needs are emerging.   Address exhaustion is still one need (and growing).  But we also increasingly see organizations mandating IPv6 Only deployments, such as the USG, are emerging and these cannot be ignored.   Enterprises will need assistance with the deployment of IPv6 and there needs to be awareness of what the potential issues are and in some cases how to address them.   Towards these ends, the V6OPS Working Group is working in several related areas and even conducts “Side Meetings” to expressly address Enterprise issues. 
  3. Extension Headers.  EHs are intrinsic to many core IPv6 functions and also allow the protocol to be extended for current and future enhancements.   But there may be issues, in certain situations, with EHs being dropped, filtered or not handled optimally.    The INTC is taking the lead in providing related research, testing and even solutions.   This area is important to all organizations, vendors, networks and developers.  The INTC efforts focus on finding problems that exist, determining causal factors, and proposing & testing related solutions.  Many are referring to this focused approach as the “Bug Brigade” and the value provided has been recognized by many at the IETF.  The BB is gaining the respect of many, including Cloud and CDN vendors wanting to partner with us.   It is critical that these efforts continue, as they are success factors for all IPv6 deployments and their future viability

 

The next IETF meeting is scheduled for  November 04-10, in Prague, CZ               

The remaining sections of this document describe technical details,  several examples of Working Group and other  Sessions attended at IETF 117 and some information on industry changes, problems or progress.       These sections may be technically intense and may require detail and clarification, which I am happy to provide, at any time. 

 

PRE CONFERENCE   –     INFORMATION  / ACTIVITIES & EVENTS

These two separate sub sections are a brief overview events, information  and activities which occur prior to the actual IETF conference.  Pre Conference  Information, is focused on topic(s), which are currently or most critical interest to large enterprise network operators.     Pre Conference activities,  are events scheduled during the weekend prior to the IETF conference and usually include the HACKATHON, IEPG and sometimes other events. 

 

The first sub section (Information)  topic in this report focuses on a general overview on IPv6, which remains a critical network  topic for Enterprises to address in the next 2-3 years,  Any organization or enterprise which will need IPv6, for any reason (additional addresses, expansions, mergers, increased geography customer scope, business partner / customer requirements,  and for many other reasons),  should be prepared for production IPv6 operation,  Should begin preparing now, as this is probably a 2-3 year long initiative.

 

 

 

 

PRE CONFERENCE   –     INFORMATION

 

 

 

FOCUS TOPIC: IPV6  STATUS, TESTING AND RESULTS  

 

  • Many sessions addressed IPv6. IPv6 continues to grow and become more critical for all  Enterprises and networks to address.     A great deal of related status information is presented below, in the following order:
  • Overall percentage of internet traffic which uses IPv6, continues to grow at an significant rate.
  1. The first screen print shows the percentage of users that access Google over IPV6, is  continuing to grow at an a very significant rate and is now at 45%, which is up from 40% a year ago.     There are other organizations reporting slightly different results, but the Google metrics have been an accepted gauge for many years. 
  2. The second screen print below is of ISOC data illustrating similar information, by country and application.
  3. The third screen print shows percentage of traffic on the top ISPs which is now IPv6. Please note that many ISPs are approaching all IPv6 status,  in particular Reliance in India,  and T-Mobile, both of which have many areas that are completely IPv6.   Reliance has demonstrated amazing growth in several areas this past year,  and should be a company to watch,  when they begin deployments in North America.   Note:These statistics may not be updated regularly, in the future. 
  4. The fourth screen print shows the prevalent conversion technologies deployed by many of the ISPs.
  5. The final area shows contrasts between v4 and v6 performance, in various common network scenarios.   

 

 

 

SCREEN PRINT #1

 

SCREEN PRINT #2

 

 

 

 

 

 

SCREEN PRINT #3

 

 

 

 

 

 

 

 

 

SCREEN PRINT #4

ISP (name) Country Transition Mechanism (NAT64/464xlat, 6rd, DS-Lite, Dual Stack, …) Network Type (mobile, DSL, fiber, cable, satellite,…)
AFAIR Cablecom   DS-Lite  

Altibox

 DK,NO 6RD Fibre
AT&T US ? Mobile
AT&T US 6rd AT&T Old PPPoE ADSL

AT&T Uverse

 US Native IPv6 (Dual Stack) 802.1x “IPDSL” over ADSL/ADSL2/ADSL2+/VDSL and Fiber
Bouygues FR 464XLAT  

BT/EE

 GB 464XLAT Mobile
CenturyLink US 6rd  
Charter US MAP-T (EFT) DOCSIS
Comcast US dual stack DOCSIS

Digicel

 TT Dual Stack Mobile
DNA FI dual stack  
Eir IE dual stack VDSL2 & FTTH
Forthnet GR Dual-Stack, DS-Lite DSL
FPT VN dual stack LTE
Free FR 6rd  
Get NO Dual stack DOCSIS
Ice NO Dual stack 3GPP
Jazztel   dual stack, DS-Lite fibre?
Kabel Deutschland DE DS-Lite DOCSIS
MTS RU dual-stack  
Netassist UA dual stack fibre, ETTH
O2 CZ DS-Lite DSL
Orange Espana ES dual stack, DS-Lite Fibre
Orange France FR Dual-stack Mobile
Orange France FR Dual-stack ADSL, VDSL, Fibre

Orange Polska

 PL 464XLAT Mobile
Orange Polska PL DS-Lite DSL and fibre
Orange Slovakia SK DS-Lite DSL
OTE GR Dual-stack / lw4o6 xDSL
Proximus BE dual stack DSL
RCS & RDS RO Dual Stack FTTH
Reliance Jio IN MAP-T, Dual-stack DOCSIS
Rogers CA Dual Stack Wireline
Rogers CA NAT64/XLAT464 Wireless
SK Telecom KR 464XLAT  

Sky UK

 UK Dual Stack DSL + Fibre
Sonic.net US 6rd Wireline
Sprint US 464XLAT Mobile
Swisscom CH 6rd DSL and fibr
T-Mobile US 464XLAT, NAT64 Mobile
Tele2 SE Dual stack 3GPP
Telecentro AR    
Telenet BE dual stack DOCSIS
Telenor NO Dual stack GPON, DOCSIS, xDSL, 3GPP
Telstra AU 464XLAT Mobile
Telus CA 464XLAT?  
Transix JP DS-Lite  
Tre DK,SE Dual stack 3GPP
Verizon FIOS US IPv4 only Fibr
Verizon Wireless US Dual-stack Mobile
Virgin Media (LGI) IE DS-Lite Docsis
Ziggo NL DS-Lite Docsis
JPNE JP MAP-E  

 

 

 

 

PERFORMANCE COMPARISONS BETWEEN IPV4 AND IPV6

 

The final displays below are indicative of a trend which began early in 2015.   That is, that most carriers and ISPs and platforms/networks in general,  are beginning to optimize  their infrastructures to prefer  IPv6.   One significant area where this begins to manifest intself to customer environments,  is in hop counts and latency,  which translates to reliabilty,  availability and improved performance for customers and users.  

 

Below are several live recorded examples. 

 

 

 

C:\Users\e104040>ping google.com

 

Pinging google.com [142.251.215.238] with 32 bytes of data:

Reply from 142.251.215.238: bytes=32 time=35ms TTL=114

Reply from 142.251.215.238: bytes=32 time=42ms TTL=114

Reply from 142.251.215.238: bytes=32 time=37ms TTL=114

Reply from 142.251.215.238: bytes=32 time=51ms TTL=114

 

Ping statistics for 142.251.215.238:

    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

    Minimum = 35ms, Maximum = 51ms, Average = 41ms

 

 

C:\Users\e104040>ping -6 www.google.com

 

Pinging www.google.com [2607:f8b0:400a:800::2004] with 32 bytes of data:

Reply from 2607:f8b0:400a:800::2004: time=26ms

Reply from 2607:f8b0:400a:800::2004: time=25ms

Reply from 2607:f8b0:400a:800::2004: time=26ms

Reply from 2607:f8b0:400a:800::2004: time=24ms

 

Ping statistics for 2607:f8b0:400a:800::2004:

    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

    Minimum = 24ms, Maximum = 26ms, Average = 25ms

 

 

C:\Users\e104040>tracert  -4 google.com

 

Tracing route to google.com [142.250.69.206]

over a maximum of 30 hops:

 

  1     1 ms     1 ms     2 ms  rtrb-wireless.meeting.ietf.org [31.133.128.3]

  2    43 ms    56 ms     6 ms  e0-4.core2.sfo1.he.net [64.62.134.4]

  3     8 ms     7 ms     8 ms  100ge3-1.core4.fmt2.he.net [72.52.92.25]

  4     *        *        *     Request timed out.

  5    10 ms     7 ms    22 ms  eqixsj-google-gige.google.com [206.223.116.21]

  6     7 ms     7 ms    10 ms  108.170.242.253

  7     6 ms     5 ms     6 ms  142.251.246.129

  8    29 ms    32 ms    36 ms  142.250.56.34

  9    28 ms    28 ms    46 ms  142.251.64.1

 10    51 ms    30 ms    32 ms  74.125.243.177

 11    29 ms    28 ms    30 ms  142.251.48.211

 12    29 ms    33 ms    27 ms  sea30s08-in-f14.1e100.net [142.250.69.206]

 

Trace complete.

 

C:\Users\e104040>tracert  -6 google.com

 

Tracing route to google.com [2607:f8b0:400a:805::200e]

over a maximum of 30 hops:

 

  1     2 ms    11 ms    18 ms  rtrb-wireless.meeting.ietf.org [2001:67c:370:128::3]

  2     5 ms     5 ms     6 ms  e0-4.core2.sfo1.he.net [2001:470:112::1]

  3     *        *        *     Request timed out.

  4     7 ms     7 ms     6 ms  eqixsjc-v6.google.com [2001:504:0:1:0:1:5169:1]

  5     8 ms     8 ms     8 ms  2001:4860:0:1005::e

  6     8 ms     7 ms     8 ms  2001:4860::c:4001:13cf

  7    30 ms    27 ms    27 ms  2001:4860::c:4002:97e0

  8    27 ms    28 ms    28 ms  2001:4860::9:4002:a9e6

  9    30 ms    27 ms    27 ms  2001:4860:0:5::1

 10    26 ms    26 ms    26 ms  2001:4860:0:1::51ab

 11    25 ms    26 ms    34 ms  sea30s08-in-x0e.1e100.net [2607:f8b0:400a:805::200e]

 

Trace complete.

C:\Users\e104040>ping -6  akamai.com

 

Pinging akamai.com [2600:1404:6400:1681::b63] with 32 bytes of data:

Reply from 2600:1404:6400:1681::b63: time=44ms

Reply from 2600:1404:6400:1681::b63: time=43ms

Reply from 2600:1404:6400:1681::b63: time=44ms

Reply from 2600:1404:6400:1681::b63: time=43ms

 

Ping statistics for 2600:1404:6400:1681::b63:

    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

    Minimum = 43ms, Maximum = 44ms, Average = 43ms

 

 

 

C:\Users\e104040>tracert   -6  akamai.com

 

Tracing route to akamai.com [2600:1406:6c00:182::b63]

over a maximum of 30 hops:

 

  1     3 ms     3 ms     2 ms  2001:67c:370:1998::3

  2     7 ms     5 ms     7 ms  e0-4.core2.sfo1.he.net [2001:470:112::1]

  3     *        *        *     Request timed out.

  4     *        *        *     Request timed out.

  5     *        *        *     Request timed out.

  6    15 ms    23 ms    28 ms  eqix-la1.akamaitechnologies.com [2001:504:0:3:0:2:940:3]

  7    15 ms    18 ms    14 ms  g2600-1406-6c00-0182-0000-0000-0000-0b63.deploy.static.akamaitechnologies.com [2600:1406:6c00:182::b63]

 

Trace complete.

 

 

 

C:\Users\e104040>ping -4 akamai.com

 

Pinging akamai.com [23.10.201.195] with 32 bytes of data:

Reply from 23.10.201.195: bytes=32 time=14ms TTL=50

Reply from 23.10.201.195: bytes=32 time=14ms TTL=50

Reply from 23.10.201.195: bytes=32 time=14ms TTL=50

Reply from 23.10.201.195: bytes=32 time=14ms TTL=50

 

Ping statistics for 23.10.201.195:

    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

    Minimum = 14ms, Maximum = 14ms, Average = 14ms

 

C:\Users\e104040>

 

C:\Users\e104040>tracert  -4 akamai.com

 

Tracing route to akamai.com [23.40.20.146]

over a maximum of 30 hops:

 

  1     2 ms     2 ms     1 ms  rtrb-wireless.meeting.ietf.org [31.133.128.3]

  2     6 ms     6 ms     6 ms  e0-4.core2.sfo1.he.net [64.62.134.4]

  3    17 ms     6 ms     6 ms  port-channel11.core2.pao1.he.net [184.105.81.85]

  4     7 ms     *        *     port-channel13.core3.sjc2.he.net [184.104.198.253]

  5     *        *        *     Request timed out.

  6    73 ms    73 ms    72 ms  100ge0-36.core2.phl1.he.net [184.105.222.2]

  7     *        *        *     Request timed out.

  8    69 ms    69 ms    70 ms  a23-40-20-146.deploy.static.akamaitechnologies.com [23.40.20.146]

 

Trace complete.

 

C:\Users\e104040>tracert  -6 akamai.com

 

Tracing route to akamai.com [2600:1409:9800:987::b63]

over a maximum of 30 hops:

 

  1     2 ms     1 ms     2 ms  rtrb-wireless.meeting.ietf.org [2001:67c:370:128::3]

  2     7 ms     6 ms     5 ms  e0-4.core2.sfo1.he.net [2001:470:112::1]

  3     *        *        *     Request timed out.

  4     *        *        *     Request timed out.

  5     *        *        *     Request timed out.

  6    24 ms    23 ms    23 ms  v6-six-sea2.netarch.akamai.com [2001:504:16::168:0:51cc]

  7    23 ms    25 ms    23 ms  vlan101.r13.spine101.sea01.fab.netarch.akamai.com [2600:1409:a800:20e::1]

  8    37 ms    37 ms    24 ms  vlan113.r02.leaf102.sea01.fab.netarch.akamai.com [2600:1409:a800:1206::1]

  9    23 ms    25 ms    29 ms  vlan101.r11.tor102.sea01.fab.netarch.akamai.com [2600:1409:a800:2a0b::1]

 10    33 ms    25 ms    22 ms  g2600-1409-9800-0987-0000-0000-0000-0b63.deploy.static.akamaitechnologies.com [2600:1409:9800:987::b63]

 

 

When on the V6 ONLY Network

 

Wireless LAN adapter Wi-Fi:

 

   Connection-specific DNS Suffix  . : meeting.ietf.org

   Description . . . . . . . . . . . : Intel(R) Dual Band Wireless-AC 8265

   Physical Address. . . . . . . . . : FC-77-74-D4-44-F0

   DHCP Enabled. . . . . . . . . . . : Yes

   Autoconfiguration Enabled . . . . : Yes

   IPv6 Address. . . . . . . . . . . : 2001:67c:370:1999:49cd:d395:fce3:3dea(Preferred)

   Link-local IPv6 Address . . . . . : fe80::3faf:fbcd:a5bf:5d06%12(Preferred)

   Autoconfiguration IPv4 Address. . : 169.254.188.52(Preferred)

   Subnet Mask . . . . . . . . . . . : 255.255.0.0

   Default Gateway . . . . . . . . . : fe80::1999:1%12

   DHCPv6 IAID . . . . . . . . . . . : 117208948

   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-28-35-8D-EE-B0-0C-D1-C2-78-2B

   DNS Servers . . . . . . . . . . . : 2001:67c:370:229::7

                                       2001:67c:370:229::6

   NetBIOS over Tcpip. . . . . . . . : Disabled

   Connection-specific DNS Suffix Search List :

                                       meeting.ietf.org

 

 

 

C:\Users\e104040>ping  bcbsm.com

Ping request could not find host bcbsm.com. Please check the name and try again.

PLEASE NOTE THAT THIS IS INDICATIVE OF THE FACT THAT IF YOUR ORGANIZATION DOES NOT SUPPORT IPV6,  AND ANOTHER NODE, NETWORK OR ORGANIZATION IS IPV6 ONLY, THEY WILL NOT BE ABLE TO REACH YOU!!!

 

 

 

 

IPV6 ONLY NETWORK

 

PING TO GOOGLE.COM OVER IPV6

 

H:\>ping google.com

 

Pinging google.com [2404:6800:4003:c00::64] with 32 bytes of data:

Reply from 2404:6800:4003:c00::64: time=3ms

Reply from 2404:6800:4003:c00::64: time=3ms

Reply from 2404:6800:4003:c00::64: time=3ms

Reply from 2404:6800:4003:c00::64: time=3ms

 

Ping statistics for 2404:6800:4003:c00::64:

    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

    Minimum = 3ms, Maximum = 3ms, Average = 3ms

 

 

 

 

PING TO FACEBOOK.COM OVER IPV6

 

H:\>ping facebook.com

 

Pinging facebook.com [2a03:2880:f108:83:face:b00c:0:25de] with 32 bytes of data:

Reply from 2a03:2880:f108:83:face:b00c:0:25de: time=200ms

Reply from 2a03:2880:f108:83:face:b00c:0:25de: time=200ms

Reply from 2a03:2880:f108:83:face:b00c:0:25de: time=200ms

Reply from 2a03:2880:f108:83:face:b00c:0:25de: time=201ms

 

Ping statistics for 2a03:2880:f108:83:face:b00c:0:25de:

    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

    Minimum = 200ms, Maximum = 201ms, Average = 200ms

 

 

PING TO BCBSM.COM OVER IPV6

 

H:\>ping bcbsm.com

Ping request could not find host bcbsm.com. Please check the name and try again.

 

 

 

3 –  CLIENT ON A NAT64  NETWORK.   WHAT HAPPENS IF THE ENTERPRISE IS IPV6 ENABLED AND WHAT HAPPENS IF THEY ARE NOT.

 

 

———————-  (NAT64 Network  in San Francisco)

 

 

 

PING TO GOOGLE.COM OVER NAT64

H:\>ping google.com

 

Pinging google.com [2404:6800:4003:c00::64] with 32 bytes of data:

Reply from 2404:6800:4003:c00::64: time=10ms

Reply from 2404:6800:4003:c00::64: time=5ms

Reply from 2404:6800:4003:c00::64: time=4ms

Reply from 2404:6800:4003:c00::64: time=3ms

 

Ping statistics for 2404:6800:4003:c00::64:

    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

    Minimum = 3ms, Maximum = 10ms, Average = 5ms

 

 

PING TO BCBSM.COM  OVER NAT64

H:\>ping bcbsm.com

 

Pinging bcbsm.com [64:ff9b::cb0:f94e] with 32 bytes of data:

Request timed out.

Request timed out.

Request timed out.

Request timed out.

 

Ping statistics for 64:ff9b::cb0:f94e:

    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

 

H:\>

 

—————

4 – PING TO CISCO.COM HAS SHORTER HOP PATH AND LOWER LATENCY WHEN USING IPV6

 

TRACE ROUTE TO CISCO.COM  OVER IPV6

H:\>tracert cisco.com

 

Tracing route to cisco.com [2001:420:1101:1::a]

over a maximum of 30 hops:

 

  1     1 ms     1 ms     1 ms  rtra-wireless.meeting.ietf.org [2001:67c:370:128::2]

  2     3 ms     5 ms     4 ms  ge-100-0-0-3.r00.sngpsi05.sg.bb.gin.ntt.net [2001:218:4000:5000::1a5]

  3     3 ms     3 ms     4 ms  ae-10.r20.sngpsi05.sg.bb.gin.ntt.net [2001:218:0:2000::b5]

  4   184 ms   185 ms   185 ms  ae-8.r22.snjsca04.us.bb.gin.ntt.net [2001:218:0:2000::65]

  5   175 ms   175 ms   176 ms  ae-19.r01.snjsca04.us.bb.gin.ntt.net [2001:418:0:2000::7e]

  6   168 ms   184 ms   170 ms  ae-0.a02.snjsca04.us.bb.gin.ntt.net [2001:418:0:2000::2f2]

  7   188 ms   191 ms   188 ms  ntt-gw.sffca.ipv6.att.net [2001:1890:1fff:413:192:205:37:57]

  8   214 ms   214 ms   215 ms  sffca22crs.ipv6.att.net [2001:1890:ff:ffff:12:122:149:138]

  9   213 ms   215 ms   212 ms  la2ca22crs.ipv6.att.net [2001:1890:ff:ffff:12:122:31:133]

 10   215 ms   219 ms   215 ms  dlstx22crs.ipv6.att.net [2001:1890:ff:ffff:12:122:2:81]

 11   208 ms   208 ms   209 ms  dlstx405me3.ipv6.att.net [2001:1890:ff:ffff:12:122:119:9]

 12     *      232 ms     *     2001:1890:c00:8701::11b7:3f7f

 13   212 ms   211 ms   212 ms  rcdn9-cd2-dmzbb-gw2-ten1-1.cisco.com [2001:420:1100:6::1]

 14   209 ms   209 ms   209 ms  rcdn9-cd1-dmzdcc-gw1-por2.cisco.com [2001:420:1100:2::1]

 15   213 ms   213 ms   245 ms  rcdn9-16b-dcz05n-gw2-por1.cisco.com [2001:420:1100:10c::1]

 16   210 ms   207 ms   209 ms  www1.cisco.com [2001:420:1101:1::a]

 

Trace complete.

 

============= 

=============  

 

PING  TO CISCO.COM  OVER IPV6

H:\>ping cisco.com

 

Pinging cisco.com [2001:420:1101:1::a] with 32 bytes of data:

Reply from 2001:420:1101:1::a: time=208ms

Reply from 2001:420:1101:1::a: time=207ms

Reply from 2001:420:1101:1::a: time=208ms

Reply from 2001:420:1101:1::a: time=208ms

 

Ping statistics for 2001:420:1101:1::a:

    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

    Minimum = 207ms, Maximum = 208ms, Average = 207ms

 

:\>nslookup cisco.com

Server:  ntp.meeting.ietf.org

Address:  2001:67c:370:229::7

 

Non-authoritative answer:

Name:    cisco.com

Addresses:  2001:420:1101:1::a

          72.163.4.161

 

 

PING  TO CISCO.COM  OVER IPV4

H:\>ping 72.163.4.161

 

Pinging 72.163.4.161 with 32 bytes of data:

Reply from 72.163.4.161: bytes=32 time=226ms TTL=241

Reply from 72.163.4.161: bytes=32 time=255ms TTL=241

Reply from 72.163.4.161: bytes=32 time=275ms TTL=241

Reply from 72.163.4.161: bytes=32 time=226ms TTL=241

 

Ping statistics for 72.163.4.161:

    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

    Minimum = 226ms, Maximum = 275ms, Average = 245ms

 

H:\>

 

 

 

 

========== 

 

 

 

 

 

PRE CONFERENCE   –     ACTIVITES & EVENTS 

 

 

SUNDAY   JULY 23, 2023

 

 

 

HACKATHON

 

 

PDMv2  AND EXTENSION HEADER TESTING AND RESULTS. 

 

These activities are still very active but none of our team(s) attended the Hackathon during IETF 117.

 

 

 

IEPG

 

EXTENSION HEADER TESTING ON CLOUD PLATFORMS

Nalini  Elkins

https://datatracker.ietf.org/meeting/117/materials/slides-117-iepg-sessa-deep-dive-into-ipv6-extension-header-testing-on-cloud-platforms-00

This effort has been ongoing for over a year and a half.   With several years likely left.

Many are doing large scale measurement’s     This effort focuses on issues and how to address them.

Testing uses real data. 

When adding EH Cloud to Standalone server does not work.  Same sessions without EH work fine.

Many third party boxes may exist.  What is not supporting them. 

Inside Same Cloud then sessions with EHs work fine. 

Link Local within Cloud works OK too.

2nd CLOUD PROVIDER

Seems to work but with one exception that ICMP Checksum not computed correctly.    Only when EHs are present.

NEXT STEPS

Test with more Clouds, routers, ISPs, LBs, OSs

Need to test ALL extension headers. 

Will be a multi year project. 

 

ROADMAP FOR MORE SECURE GLOBAL INTERNET ROUTING SYSTEM

Fastly.   Oscar Lukefahr

https://datatracker.ietf.org/meeting/117/materials/slides-117-iepg-sessa-2023-2028-roadmap-for-a-more-secure-global-internet-routing-system-00

RPKI Route Origin Validation.   RPKI-ROV

Can get errors in routing tables that can be typos or malicious attempts. 

AS Spoofing is another issue and is usually malicious. 

Shows up as an “Extra” port and is hard to find/diagnose

Most tier ones have implemented ROV  not Sparkle, Zayo and Deutsche Telecom.      Is Sparkle TI?

OpenBGPD + BIRD +FRRouting support this.

ASPA. Autonomous System Provider Authentication.   Many ISPs and Tier ones PLAN to support. 

BGPsec.

Most valuable sessions are often Private Peering Sessions. 

Overall, Internet Routing Security is at 42%

 

 

 

 ENHANCEMENTSS TO BMP IN FRR ROUTING

Maxence Younsis  INSA

 

 

BGP ATTRIBUTE ESCAPE

Jeffrey Hass   Juniper.  

https://datatracker.ietf.org/meeting/117/materials/slides-117-iepg-sessa-bgp-attribute-escape-00

Any case where BGP has a path attribute that is out of bounds. 

Internet Drafts should have a section between or including Security and Operational considerations!

Do you have an operational mindset or a Security mindset.  

 

 

 

 

 

 

DETAILED BREAKOUT SESSIONS ATTENDED

 

The DETAILED BREAKOUT SESSIONS ATTENDED,  information compiled below is in brief, bullet form. Greater detail, materials, slides, clarification, and other associated information can be made available upon request.   I personally welcome ANY related  questions or discourse!  Listed below are the sessions that I attended.   There are many other topics/areas covered by the IETF, so if there is a category you do not see, please ask.  A couple other sessions were attended and materials gathered for still more, so even if not itemized below information may still be available.   

 

Most of these sessions are standing Working Group meetings.   As such, they generally  do not provide much background, just updates and new issues or developments.    Some of the notes may require clarification or even appear cryptic, so please do not hesitate to ask  clarification questions or seek more detailed information. 

 

 

MONDAY  JULY 24, 2023

 

 

ACM/IRTF: APPLIED NETWORKING RESEARCH WORKSHOP  

 

·        Phillip Lewis

 

 

 

IPPM: IP PERFORMANCE MEASUREMENT WORKING GROUP   

 

 

ACME:   AUTOMATED CERTIFICATE MANAGEMENT ENVIRONMENT    

 

  

 

TUESDAY JULY 25,  2023

 

 

V6OPS: IPV6 OPERATIONS  WORKING GROUP   

 

   

6LO: IPV6 OVER NETWORKS OF RESOURCE-CONSTRAINED NODES WORKING GROUP   

 

·       Transmission of SCHC-compressed packets over IEEE 802.15.4 networksEH LIMIT DRAFT ·       https://datatracker.ietf.org/meeting/117/materials/slides-117-6lo-transmission-of-schc-compressed-packets-over-ieee-802154-networks-02·        ·       IPv6 Neighbor Discovery Prefix Registration ·       Pascall Thubert ·       https://datatracker.ietf.org/meeting/117/materials/slides-117-6lo-ipv6-neighbor-discovery-prefix-registration-00·       Capability that was missing was to restart a prefix.·       P field expanded to 3 bits. ·       WHAT BECOMES OF DAD?·        ·       Architecture and Framework for IPv6 over Non-Broadcast Access·       https://datatracker.ietf.org/meeting/117/materials/slides-117-6lo-architecture-for-ipv6-over-nbma-networks-update-1-00·        Should l2 and l3 be decoupled and what does that mean?  Debated in V6OPS as well.  ·        ·       Transmission of IPv6 Packets over ShortRange Optical Wireless Communications (IPv6 over OWC)·       https://datatracker.ietf.org/meeting/117/materials/slides-117-6lo-transmission-of-ipv6-packets-over-shortrange-optical-wireless-communications-ipv6-over-owc-00·         INTAREA: INTERNET AREA WORKING GROUP   ·       IP Addressing with References (IPREF)·       https://datatracker.ietf.org/meeting/117/materials/slides-117-intarea-ip-addressing-with-references-ipref-00·       May speed up v6 deployment? ·       How does this work?    Don’t really need IP address?  No real v4 address shortage?    ·       Is this the IPv10 guy?     ·        ·       Communicating Proxy Configurations in Provisioning Domains·       Tommy Pauly·       https://datatracker.ietf.org/meeting/117/materials/slides-117-intarea-pvd-proxy-discovery-00·       WPAD and PAC exist today to determine if traffic should go through proxy or not·       A proxy is a PVD·       Update 8801?·       Should do TLS to Proxy.·        ·       TRUSTED DOMAIN SRV6 ·       Andrew Alston·       https://datatracker.ietf.org/meeting/117/materials/slides-117-intarea-trusted-domain-srv6-00·        SRV6 needs to operate in a secure and fail closed manner.  Re writing SRV6 is not an option.  And avoid solutions that require changes in silicon. ·       Trusted Domain SRV6 Ethertype·       Much discussion about the pros and cons of a new Ethertype!·        ·       Civic Location and Geospatial Coordinate Support in IPv6 ND·       RFC 4676 has standardized DHCP options for delivering the Civic Location of the client, while RFC 6225 has defined DHCP options for delivering the Geospatial coordinates of the client.  However, these corresponding options are missing in IPv6 Neighbor Discovery protocols.·       This proposal aims to address this gap by introducing the necessary options for IPv6 Neighbor Discovery to provide accurate location information.  ADD: ADAPTIVE DNS DISCOVERY ·       Delegated Credentials to Host Encrypted DNS Forwarders on CPEs·       https://datatracker.ietf.org/meeting/117/materials/slides-117-add-delegated-credentials-to-host-encrypted-dns-forwarders-on-cpes-00·           

 

 

 

 

WEDNESDAY JULY 26, 2023

 

 

SPRING: SOURCE PACKET ROUTING IN NETWORKING  WORKING GROUP   

 

  • CompressedSRv6SegmentList EncodinginSRH
  • https://datatracker.ietf.org/meeting/117/materials/slides-117-spring-compressed-srv6-segment-list-encoding-in-srh-02
  • ICMPv6 error processing.   In the presence of C-SIDS.   Similar to EH issues?
  •  
  • BFD in Segment Routing Networks Using MPLS Dataplane
  • Greg Mirsky
  • https://datatracker.ietf.org/meeting/117/materials/slides-117-spring-bfd-in-sr-mpls-00
  • The Bidirectional Forwarding Detection (BFD) protocol is a simple hello mechanism that detects failures in a network. A pair of routing devices exchange BFD packets. The devices send hello packets at a specified, regular interval.
  •  
  • Enhanced Performance Measurement Using Simple TWAMP in Segment Routing Networks
  • Much reference to IPPM work. Editorial comment is that these efforts are “Active” measurements and address different rquiremetns and/or provide different value than “Passive” measurement techniques, such as PDM.
  •  
  • PROBLEM STATEMENT FOR INTER-DOMAIN INTENT-AWARE ROUTING USING COLOR
  • Multicast Requirements l Ability to create multicast distribution trees that minimize latency metric
  •  

 

 

TLS:TRANSPORT LAYER SECURITY WORKING GROUP   

 

  • TLS 1.2 is frozen
  • ietf.org/meeting/117/materials/slides-117-tls-new-draft-tls-12-is-frozen-00
  • Rich Salz
  • Freeze because industry not ready for deprecation yet.
  • New protocols must use 1.3. Can specific 1.2
  • Ben Schwartz. What about a feature freeze as opposed to totally frozen and  bug fixes. 
  • Many industries need more time to convert to 1.3.
  • The wording should reflect that you CAN configure 1.2 securely
  • Many products still do not support1.3 and many of our network management platforms will not function if 1.3 is implemented, such as packet visibility engines and IPS systems. Intrusion Detection and Prevention. 
  •  
  •  
  • New Post-Quantum Signatures on the Horizon
  • https://datatracker.ietf.org/meeting/117/materials/slides-117-tls-new-post-quantum-signature-algorithms-on-the-horizon-00
  •  

 

 

 

THURSDAY JULY 27, 2023

 

 

TSVWG:TRANSPORT AREA  WORKING GROUP 

 

Low Latency, Low Loss, and Scalable Throughput (L4S) Internet Service: Architecture
RFC 9330

  • Reducing latency by significant amounts. Hackathon demo seems to indicate this is viable and real.
  • Weekly test assignments for simplicity – 1 type of test / application per week – General measurement diagnostics (LUL, network responsiveness test, etc.) – Facetime & other video conferencing – Gaming – NVIDIA, Valve, others – Other TBD apps

 

  • Operational Guidance on Coexistence with Classic ECN during L4S Deployment

 

 

LUNCH MEETING

  • CLOUD NATIVE NETWORK AUTOMATION
  • Nephio – OLF networking

 

 

 

 

 

6MAN:IPV6 MAINTENANCE WORKING GROUP   

 

  • Representing IPv6 Zone Identifiers in Uniform Resource Identifiers
  • Brian Carpenter and Bob Hinden
  • Make browsers accept URLs with interface IDs
  • Awaiting IESG feedback.
  • WC3 is trying to ignore this.    Erik Clien continues to work with them but appears frustrated.
  • Another potential use case could be in DNS resolvers 
  • Is there an issue with how does this interface with SNI or TLS in general?

 

 

 

 

 

 

IPV6 SIDE MEETING    

 

Huides, Alexandra  AWS

 

IPV6 ADDRESSING AND ARCHITECTURE WITH THE AWS CLOUD

Huides, Alexandra  AWS

 

  • DEPLOYING
  • 4O% of traffic is IPv6
  • Is the v6 header length an issue in any way?    Including performance.
  • Start with an addressing plan.
  • Extension Headers/??
  • No ULA support today. Only GUA
  • Can bring your own registered addresses and use in VPCs
  • What prefix do customers get. /56.    Then that /56 is under the control of the customer.    And then all subnets are /64.   Max of 256 subnets, which is a soft limit. 
  • Default route table has both v4 and v6 entries and cannot be removed. So everything within the VPC can talk to everything else. 
  • DNS hierarchy . Private DNS then Public DNS.
  • Can I have a mix of subnets within the VPC.   V4 and V6. Can also do ipv6 only subnet. 
  • Internet gateway attached to VPC.  V4 implements a one to one NAT.  
  • Gateway has ACLs to control traffic.
  • V4 default route is to NAT gateway.
  • Running NAT64 DNS64 for V6 clients accessing V4 only servers.
  • Summarization is very important as the number of addresses gets larger.
  • AWS Privatelink.
  • V4 to V6 uses the AWS elastic load balancers. All use dual stack. 
  • Application LBs, Network LBs, and
  • All LBs can also be proxys
  • EKS now supports v6
  • AWS Network Firewall now has full support for v6.
  • Ethena now has full support as well.

 

  • USG IPV6 and PRIVATE INDUSTRY
  • Nick Buraglio and Phillip Tiessel
  • What will the effect of the latest USG IPv6 mandates have upon private industry / enterprises?
  • DOE Network.
  • M-21-07 20% 50% and 80% by 2025
  • How are suppliers or partners affected.
  • Do we need to have products that support v6 only, use v6 only, or use v6 on connections with the agency you are doing business with?
  • To address confusion with related addressing structures, refer to and / or support rfc 5952
  • Federal acquisition rules.   Ed Horley.
  • Actual mandates, numbers, percentages, dates this time. Reports required monthly.    It seems REAL this time. 
  • The rules and statements for procurement areas should be saying something link “Product needs to be able to operate without V4 “!!!
  • It is likely the USG and Agencies will not terminate existing business if partners do not deploy IPv6, but next RFP’s and Bids will likely mandate it or reduce chances of partners getting/retaining USG contracts.
  • Issues with multi homing in V6.   Nick solved with Netwatch  scripts but Jens draft may be a better solution.  There are other potential solutions as well.