- ipv6-wg - mailman.ripe.net

Re: [ipv6-wg] [Snac] [v6ops] "router cascade with DHCPv6-PD"
by Michael Richardson 22 Jan '23

22 Jan '23

Ole Trøan <otroan(a)employees.org> wrote: >>>> The lack of a standardized way to communicate DHCPv6-server PD to >>>> DHCPv6-relay, and the expectation that the relay would just *snoop* = >>>> on the >>>> DHCPv6-PD contents has bugged me for a long time. If we are going to >>>> recommend that they act as relays, then I'd like to fix that. >>> If DHCP is used for prefix assignment inside of a site, the relay does >>> not need to do route injection for the requesting router. The RR can >>> simply advertise the assigned prefix in routing. >> >> a) it's actually cross-site. > Elaborate please. We have three entities. 1) the STUB router or other downstream "home" router. 2) the CPE router which is at the "north" side of the home LAN, and on the south side of the WAN/DSL/CMTS link. 3) The ISP DHCP server which is somewhere inside the ISP, with a DHCP relay at the BMS or Cable Head end to send to it. If (2) treats a DHCP-PD request from (1) as a relay, then it would relay to (3), which would allocate a new prefix. That message would back through (3) [where it gets snooped on, and maybe, yes, injected into the ISP routing system]. Then it would relayed to (2), which would then relay it to (1). (2) has to do something to route the prefix to (1), which today, means snooping on the results. But, even if the (2) is operated by the ISP, it's not part of the ISPs site. The south side of (2) belongs to the home owner. The prefix needs to be routed from (2) to (1). There is no routing protocol in the home at this time(alas!), so there is nothing to "inject" it into. -- Michael Richardson <mcr+IETF(a)sandelman.ca> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide

1 0

Re: [ipv6-wg] [Snac] [v6ops] "router cascade with DHCPv6-PD"
by Michael Richardson 17 Jan '23

17 Jan '23

Ole Trøan <otroan(a)employees.org> wrote: >> The lack of a standardized way to communicate DHCPv6-server PD to >> DHCPv6-relay, and the expectation that the relay would just *snoop* on the >> DHCPv6-PD contents has bugged me for a long time. If we are going to >> recommend that they act as relays, then I'd like to fix that. > If DHCP is used for prefix assignment inside of a site, the relay does > not need to do route injection for the requesting router. The RR can > simply advertise the assigned prefix in routing. a) it's actually cross-site. > Ah, you don’t want to run a routing protocol? Well, there’s your problem. b) If you can find a way to deploy OSPFv3 (or BABEL) in every home network, then I'm game. -- Michael Richardson <mcr+IETF(a)sandelman.ca> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide

1 0

Re: [ipv6-wg] [Snac] [v6ops] "router cascade with DHCPv6-PD"
by Michael Richardson 17 Jan '23

17 Jan '23

(Hi Martin, I'm just the messenger, your questions are all pretty good. For others, I think it was not obvious that they are about draft-winters-v6ops-cpe-lan-pd-00. But, more than my brain can handle right now) Ted Lemon <mellon(a)fugue.com> wrote: >> Why not honor the IA_PD size requested by the requesting router? Do you >> expect that possible another cascade router would be switched to DHCPv6 >> relay mode? > What’s the use case for this behavior? And yes, we expect routers to act as > DHCPv6 relays. I think that actually we've created an ambiguity about whether they are DHCPv6 relays or if they are full DHCPv6 servers. There are arguments both ways, and in some cases the choice is transparent to the end system, but in other ways it is not. The lack of a standardized way to communicate DHCPv6-server PD to DHCPv6-relay, and the expectation that the relay would just *snoop* on the DHCPv6-PD contents has bugged me for a long time. If we are going to recommend that they act as relays, then I'd like to fix that. Either way, Tim's v6ops draft-winters-v6ops-cpe-lan-pd-00 should clarify. LPD-1 suggests the IPv6 CE Router is a server, not a relay. -- Michael Richardson <mcr+IETF(a)sandelman.ca> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide

2 1

"router cascade with DHCPv6-PD"
by Michael Richardson 15 Jan '23

15 Jan '23

(I guess the article is in German, but google translate did a good job on it) This relates to the desire to amend RFC7084 to support "southbound" DHCPv6-PD: https://datatracker.ietf.org/doc/draft-winters-v6ops-cpe-lan-pd/ >https://www.heise.de/select/ct/2023/2/2230709000622055021 > >Alexander Traud tested 29 CPEs and tried to understand how they react to prefix changes. Router cascade with DHCPv6-PD With routers connected in a cascade, the internal network can be divided into several zones. This is useful, for example, in shared apartments that want to share an Internet connection, but each resident should still have their own (W)LAN. To do this, the front router, which is directly connected to the Internet, must pass on part of the prefix it received from the provider (DHCPv6-PD, prefix delegation) and its DHCPv6 server must ideally be able to use DHCPv6 reconfigure. Only AVM and Wavlink offered both in the test field. -- Michael Richardson <mcr+IETF(a)sandelman.ca> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide

2 2

IPv6 martian filter-set
by Nia Provia 12 Jan '23

12 Jan '23

Hi all, we want to update our BGP filtering with ipv6 martians prefixes. Querying RIPE database I am seeing two different filter-set regarding martians v6 : fltr-martian6 --> last-modified : 2015-07-28T13:39:28 fltr-martian-v6 ---> last-modified: 2020-09-10T23:40:02 Is there any recommendation/suggestion whether I should use any of these filters ? and if yes , which one ? Regards Nia

3 2

Advice for IPv6 only network /Network elements
by Agshin N 02 Jan '23

02 Jan '23

Hello, To Whom it may concern, We are small group which planning to build IPv6-only network as ISP. Legal activity started. We did some internet research and network logic topology. Nevertheless are looking best practice IPv6-only network as deployment and therefore need advice who already did it. We may send drawing topology if needed for advising. May we ask someone who is good for IPv6-only Central (data center) part implementation as router (BGP, PLAT), NAT64/DNS64, DHCPv6 sever and Translation part as well as suggestions ? Access fully are going to be FTTH and as start 3K Houses planned Namely which hardware and Software needs for it ? With Happy New 2023 Year! -- Respectfully Agshin N Skype:nagshin UTC/GMT +4 hours - Classified as Confidential -

1 0

Windows 11 now implements RFC 7217 (stable privacy addresses)!
by Fernando Gont 13 Dec '22

13 Dec '22

Folks, After over 10 (yes, *ten*) years, we have finally addressed security/privacy issues in the generation of IPv6 stable addresses in most popular operating systems. The traditional scheme/algorithm to generate stable IPv6 addresses with SLAAC required that the underlying MAC address be employed to generate the Interface Identifier. That is, the underlying MAC address would be embedded in the lower bits of an IPv6 address. This scheme allowed for host-tracking (since MAC addresses are usually globally-unique), address scanning (since addresses will follow specific patterns) and a number of other issues. In 2011, I submitted an IETF Internet-Draft proposing a scheme for generating stable addresses with SLAAC, meant to replace the traditional scheme. The scheme could be summarized and simplified as: Interface_ID = Hash(Prefix, Secret). Thus, interface identifiers would be stable within the same subnet, but vary across subnets. [Replacing the traditional scheme with this new scheme was anything but easy -- if you're curious, please check the "IPv6 Addressing" section in <https://www.si6networks.com/2020/08/06/a-brief-history-of-recent-advances-i…> ] Over time, popular operating systems and packages adopted the proposed algorithm: the Linux kernel, NetworkManager, OpenBSD's slaacd, MacOS, etc. Eventually, virtually every popular OS had adopted the scheme.... except Windows. Based on a recent note by Brian Carpenter, I ended up testing Windows 11, and I can confirm that it does implement RFC 7217 / RFC 8064! Therefore, e.g. if multiple prefixes are employed on a subnet, the stable addresses for each of such prefixes will employ a different Interface Identifier, thus avoiding the security/privacy issues discussed above -- this is really good news! Unfortunately, Windows still generates temporary addresses with the algorithm specified in RFC 4941, thus resulting in all temporary addresses for a given interface employing the same Interface Identifier (!). This problem has been addressed in RFC 8981... but it's implementation is not yet widespread, yet (it has been incorporated in e.g. the Linux kernel, though). I just hope it doesn't take Windows and others yet another 10+ years to implement RFC 8981, to finally address the remaining security/privacy issues in IPv6 address generation! [Original article with screenshots: https://www.linkedin.com/posts/fernandogont_after-over-10-yes-ten-years-we-… ] Thanks! Regards, -- Fernando Gont SI6 Networks e-mail: fgont(a)si6networks.com PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494

2 1

Minutes from RIPE 85 IPv6 WG
by Raymond Jetten 17 Nov '22

17 Nov '22

Dear list members, here are the draft minutes from RIPE 85 IPv6 wg. Please share your comments or remarks to the list so they can be adjusted. The minutes will otherwise be published in two weeks IPv6 Working Group Minutes - RIPE 85 Wednesday, 26 Oct 2022, 12:00-13:00 (UTC+2) WG co-Chairs: Benedikt Stockebrand, Raymond Jetten Scribe: Oleg Muravskiy Status: Draft Welcome, Etiquette, Approving Minutes, Co-Chair Selection IPv6 Working Group Co-Chairs Raymond reminded participants about the Code of Conduct. The RIPE 84 minutes were approved. Benedict announced that Raymond's term as co-chair had ended, but that he was happy to continue in that role. There were no further nominations or objections, so Raymond was re-appointed as co-chair. Path Tracing Pablo Camarillo, Cisco Systems This presentation is available at: https://ripe85.ripe.net/wp-content/uploads/presentations/76-20221026-RIPE85… Pablo described the recent implementation of an addition to the IPv6 packet header extension that records the path of packets in ECMP networks and presented the use cases that were enabled by this feature. Leandro Bertholdo, University of Twente, asked how this addition was different from the IPv4 registration option. Pablo replied that the main difference in this approach was that they recorded the information at the line speed of the basic packet forwarding pipeline, and used only 3 bytes for each node. Leandro asked the presenter if they recorded an ID of the router that the packet passed. Pablo replied that they recorded a sequence of interface ID. Leandro asked if it was for the input interface or the output. Pablo replied that they recorded an ID of the output interface at each one of the routers Alexander Azimov, Yandex, asked if this would work in the MPLS core. Pablo said that this was possible, but that for the moment it was only implemented for IPv6. Open Source NAT64 Implementations Nico Schottelius, ungleich This presentation is available at: https://ripe85.ripe.net/wp-content/uploads/presentations/74-ripe85-open-sou… Nico showed a comparison of different open source implementations of NAT64, and asked the audience to provide more feedback and point out implementations they missed. Jan Žorž, 6connect, asked Nico if they had tried a VPP implementation as it was very fast. Nico said that he hadn't but that it was nice to know about it. Urban Suhadolnik, University of Ljubljana, asked if the presenter knew of any CLAT implementation, possibly for Windows, as the user-space implementation of CLAT was missing. Nico said that he couldn't answer the question as he was not familiar with this the topic. Deploying IPv6-Mostly Access Networks Ondřej Caletka, RIPE NCC This presentation is available at: https://ripe85.ripe.net/wp-content/uploads/presentations/9-RIPE85-Deploying… Ondřej presented an "IPv6-mostly" network that was implemented at this RIPE Meeting, which combined IPv6 functionality only for devices that supported it, and traditional dual-stack for other devices, all in the same network. Leonard Wagner, IN-Berlin e.V, asked since which Android PREF64, DHCP option 108 and CLAT were supported. Ondřej replied that version 11 and above were supported by the vendor, but that he was not sure about older versions. Michael Richardson, one of the authors of the IPv4-only option, noted that when he developed this feature he never imagined that people would deploy it on DHCP servers and not change anything. He added that it was interesting to see how it worked because they assumed that DHCP servers would not allocate addresses and therefore would not run out of addresses in the pool. So it was cool to see that it just worked without doing that. He further said that for any connect, if the client was v4-only, and was just creating a v4-only UDP encapsulated thing that the local end of course had no idea what to do with, it had to be encapsulated in a v6 packet to send it. He added that he thought CLAT would be of no help but that it might work on Mac OS but not on other systems. He mentioned that IOS would never work until it went to v6 and that the Cisco people should be embarrassed about this. Veronika McKillop, UK IPv6 Council, asked which DHCP servers supported RFC8925. Ondřej replied that this was option 108 and that Kea, at least, did not support it. He added that there were two options. If you have enough addresses for the IPv4 pool, any server that allowed setting a custom option could be used. If there was any special support for this feature, the server would simply respond with option 108 and not allocate an address from the pool. He stated that he was not aware of such an implementation, as even Kea cannot be used in this way. He added that if the pool was empty, it would not even respond and that this was an interesting feature to implement for DHCP server producers. Jordi Palet Martínez, The IPv6 Company, said that it was worth mentioning that most of the CLAT implementations just used a default NAT64 prefix (the WKP). He added that there was only a single translation when using the CLAT and that two translations were only needed if there were no DNS64 (https://datatracker.ietf.org/doc/rfc8683) He said that even if your network was using NAT, NAT64 would also work well. Radek Zajic via Meetecho shared that the CLAT on iOS 16 also worked in apps requiring unix/raw sockets too (e.g. Hurricane Electric Network Tools can ping IPv4-only targets via the CLAT). Ondřej thanked Radek for his comment. Round Up and Thanks IPv6 Working Group Co-Chairs Raymond thanked all participants and the RIPE NCC and closed the session. For Internal Use Only

1 0

SLAAC and Broadcast RA
by Xuo Guoto 02 Nov '22

02 Nov '22

Dear WG, Apologies if this mail is off topic here. I have a question about BCOP-690 wrt SLAAC BCOP-690 says: Using a /64 prefix from a dedicated pool of IPv6 prefixes is the most common scenario and currently the best practice. A separate block of IPv6 space is allocated for the WAN links to the end customer CPEs, so that when CPE connects to the network and performs router discovery, a /64 prefix is used to number both ends of the connection. My understanding of this recommendation is that in an ISP scenario, each RG will be assigned a seperate /64 prefix for CPE WAN. The ISP BRAS or BNG is also expected to send periodic multicast RA. My question is how a multicast RA can be sent to a VLAN, in which each RG is expected to have a different /64 prefix? R-43 of TR-177 says: The BNG MUST be configurable to send multicast RA messages that do not contain a Prefix Information Option (PIO), in order to advertise the default router address. R-44 says: The BNG SHOULD support sending periodic and solicited multicast RA messages having the unicast MAC address of the RG or of the hosts behind a bridged RG (see RFC 6085 [26]). Reading these two together, is it correct to say that BNG should be sending out periodic multicast RA without PIO, but RA with PIO should be sent only as a reply to an RS message from RG, with multicast IPv6 destination address but with unicast link-layer address of RG. Thanks and Regards, X.

1 0

IPv6 for Dutch email servers
by Michael Richardson 28 Oct '22

28 Oct '22

A few years ago there was a presentation about getting IPv6 MX setup for various Dutch entities: Municipalities, Hospitals, etc. I couldn't find this in the agendas for the past ten RIPE meetings for IPv6. Maybe it was in a plenary. I think it was pre-pandemic. I wondered (I am suggesting) that maybe an update on this effort would be timely? -- Michael Richardson <mcr+IETF(a)sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-

5 6

APNIC IPv6 alias?
by Vasilenko Eduard 18 Oct '22

18 Oct '22

Hi all, Does APNIC has similar alias? (related to IPv6). Thanks. Ed/

1 0

web services to ipv6
by Gery Escalier 14 Oct '22

14 Oct '22

Hello everyone on the list! this is my first post, sorry if this is not the right place for my question. I currently reside in Spain, which most ISPs do not assign ipv6 to end users and with a penetration of 3% *1 I think that percentage has not changed much since 2021, it only remains to say, incredible! Previously I have used Hurricane Electric *2 when I lived in Bolivia, South America only to browse ipv6 sites. I have seen the website august.tw *3 "This is a non-profit project for learning, education and research.Our goal is to support the ever-growing internet community that wants to experiment and gain hands-on experience with the real world BGP. We provide the following services. " I am interested for personal use. -Free IPv4/IPv6 BGP tunnel-Public NAT64 server available at 2602:fc23:18::7-Public Teredo server available at teredo.august.tw Is this website known by the community?Or have any of the community users used these services?These services can be recommended for personal use? Data, I was struck by the logo shown at the bottom with a link to RIPE NCC and ARIN. I appreciate any help in this regard, thank you very much, best regards! *1 https://labs.ripe.net/documents/176/Mediterranean_country_report_Spanish_fi… *2 https://tunnelbroker.net/*3 https://august.tw/ Gery

2 1

WG co-chair selection RIPE 85
by Raymond Jetten 19 Sep '22

19 Sep '22

Dear members of the IPv6 WG list. According to our WG webpages https://www.ripe.net/participate/ripe/wg/active-wg/ipv6 it is my turn to step down as a co-chair. In a little over a month at the RIPE 85 meeting the selection will take place during the IPv6 WG session. Here is the official process: https://www.ripe.net/participate/ripe/wg/active-wg/ipv6/ipv6-wg-chair-selec… As part of the process this is a call for candidates, however I am more than happy to continue, and step up for the next term. I will open the call as from now, and the call will be closed on 30.9.2022 at 12:00 CET (Amsterdam time). If you have any questions, we , the co-chairs, will be very happy to answer them, either on the list ipv6-wg(a)ripe.net<mailto:ipv6-wg@ripe.net> or directly to us ipv6-wg-chair(a)ripe.net<mailto:ipv6-wg-chair@ripe.net>. Rgds, Raymond Jetten Raymond Jetten Senior Technology Specialist Production Cloud Services, Networks and connectivity Interconnectivity & Content Elisa Oyj Vuolteenkatu 2 33100 Tampere +358 45 6700 139 raymond.jetten(a)elisa.fi<mailto:raymond.jetten@elisa.fi> www.elisa.fi<http://www.elisa.fi/> Lisätietoa henkilötietojen käsittelystä ja tietosuojasta Elisalla https://elisa.fi/tietosuoja Mer information om Elisas hantering av personuppgifter och dataskydd https://elisa.fi/tietosuoja More information on personal data management and data protection at Elisa https://elisa.com/dataprotection ********************************************************************************************* For Internal Use Only

1 0

Mitigating the effects of SLAAC renumbering events (draft-ietf-6man-slaac-renum)
by Fernando Gont 31 Aug '22

31 Aug '22

Folks, We have been discussing the potential problems associated with SLAAC renumbering events for a while now -- one of the most common cases being ISPs rotating home prefixes, and your devices ending up with stale/invalid addresses. We have done quite a bit of work already: * Problem statement: https://datatracker.ietf.org/doc/html/rfc8978 * CPE recommendations: https://datatracker.ietf.org/doc/html/rfc9096 But there's still some work to do to address this issue: The last remaining it is to improve SLAAC such that hosts can more gracefully deal with this renumbering events. In that light, IETF's 6man has been working on this document: https://www.ietf.org/archive/id/draft-ietf-6man-slaac-renum-04.txt And we have proposed a simple algorithm for SLAAC (an extension, if you wish) that can easily help, as follows: If you (host) receive an RA that contains options, but not all of the previously-received options/information, simply send a unicast RS to the local-router, to verify/refresh that such missing information is still valid. If the information is stale, get rid of it. I presented this algorithm at the last IETF meeting (https://youtu.be/eKEizC8xhhM?t=1308) (You may find the slides here: https://datatracker.ietf.org/meeting/114/materials/slides-114-6man-improvin…) Finally, I've sent draft text for the specification of the algorithm here: https://mailarchive.ietf.org/arch/msg/ipv6/KD_Vpqg0NmkVXOQntVTOMlWHWwA/ We would be super thankful if you could take a look at the draft text (i.e., https://mailarchive.ietf.org/arch/msg/ipv6/KD_Vpqg0NmkVXOQntVTOMlWHWwA/) and provide feedback/comments. If you can post/comment on the 6man wg mailing list (https://www.ietf.org/mailman/listinfo/ipv6) that´d be fabulous. But we'll appreciate your feedback off-line, on this list, etc. (that'd still be great ;-) ) Thanks in advance! Regards, -- Fernando Gont SI6 Networks e-mail: fgont(a)si6networks.com PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494

2 1

Fwd: RFC 9288 on Recommendations on the Filtering of IPv6 Packets Containing IPv6 Extension Headers at Transit Routers
by Fernando Gont 19 Aug '22

19 Aug '22

Hi, FYI. RFC 9288, "Recommendations on the Filtering of IPv6 Packets Containing IPv6 Extension Headers at Transit Routers" (available at: https://www.rfc-editor.org/rfc/rfc9288) FWIW, IMO most of the value is in the analysis of what protocols/features use what EHs, and what would break (if anything) if packets with EHs are dropped. These other two are useful for context: * RFC 9098, "Operational Implications of IPv6 Packets with Extension Headers" (https://www.rfc-editor.org/rfc/rfc9098.html) * RFC 7872, "Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World (https://www.rfc-editor.org/rfc/rfc7872.html) Thanks! Cheers, Fernando -------- Forwarded Message -------- Subject: RFC 9288 on Recommendations on the Filtering of IPv6 Packets Containing IPv6 Extension Headers at Transit Routers Date: Thu, 18 Aug 2022 16:21:47 -0700 (PDT) From: rfc-editor(a)rfc-editor.org To: ietf-announce(a)ietf.org, rfc-dist(a)rfc-editor.org CC: rfc-editor(a)rfc-editor.org, drafts-update-ref(a)iana.org, opsec(a)ietf.org A new Request for Comments is now available in online RFC libraries. RFC 9288 Title: Recommendations on the Filtering of IPv6 Packets Containing IPv6 Extension Headers at Transit Routers Author: F. Gont, W. Liu Status: Informational Stream: IETF Date: August 2022 Mailbox: fgont(a)si6networks.com, liushucheng(a)huawei.com Pages: 33 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-opsec-ipv6-eh-filtering-10.txt URL: https://www.rfc-editor.org/info/rfc9288 DOI: 10.17487/RFC9288 This document analyzes the security implications of IPv6 Extension Headers and associated IPv6 options. Additionally, it discusses the operational and interoperability implications of discarding packets based on the IPv6 Extension Headers and IPv6 options they contain. Finally, it provides advice on the filtering of such IPv6 packets at transit routers for traffic not directed to them, for those cases where such filtering is deemed as necessary. This document is a product of the Operational Security Capabilities for IP Network Infrastructure Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor(a)rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC _______________________________________________ IETF-Announce mailing list IETF-Announce(a)ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce

2 1

New on RIPE Labs: Deploying IPv6-Mostly Access Networks
by Anastasiya Pak 02 Aug '22

02 Aug '22

Dear colleagues, Dual stack is the most common way of deploying IPv6 in access networks. A recent standard defines IPv6-mostly access networks, providing IPv4 connectivity only for legacy devices while allowing modern devices to run IPv6-only. My colleague Ondřej Caletka explored the deployment of IPv6-Mostly Access Networks. Read his article on RIPE Labs: https://labs.ripe.net/author/ondrej_caletka_1/deploying-ipv6-mostly-access-… Best regards, Anastasiya Pak Marketing & Communications Officer RIPE NCC

1 0

Call for presentations IPv6 WG @RIPE85
by Jetten Raymond 25 Jul '22

25 Jul '22

Hello All, RIPE 85 will take place from 24-28 Oktober 2022 in a hybrid format in which online and onsite participants can interact with each other using a common platform. The onsite event will take place in Belgrade Serbia. For both cases you can register here: https://ripe85.ripe.net/attend/register/ The IPv6 Working Group session is scheduled for Wednesday 26 Oktober from 12:00 . 13:00 (UTC+1) We still have some time in our session. We are looking for presentations - please email : ipv6-wg-chair (at) ripe.net if you'd like to present. Please also state if you intend to be online or onsite, and the duration of your presentation, and a short description of it. Once we have decided on the agenda, we'll contact the presenters. Hope to see many of you, On behalf of the IPv6-WG Benedikt, Jen, Ray For Internal Use Only

1 0

Minutes from RIPE84 IPv6 WG
by Jetten Raymond 25 Jul '22

25 Jul '22

Dear IPv6 WG list members, Here are the minutes from the IPv6 WG session from RIPE 84 in Berlin and online. A very big thank you to Gerardo and Ulka from the RIPE NCC. If you have any comments or remarks please let us know as soon as possible. We plan to publish the minutes at latest 2 weeks from now. Thanks, The IPv6 co-chairs IPv6 Working Group Minutes Date: Thursday, 19 May 11:00 - 12:30 (UTC+2) Chaired By: Benedikt Stockebrand, Jen Linkova, Raymond Jetten Scribe: Gerardo Viviers Welcome, Etiquette, Approving Minutes Working Group Co-Chairs Raymond Jetten, Working Group Co-Chair, welcomed everyone to the session and went over some rules of engagement. There were no questions or comments. IPv6 and the Windows 10 Firewall Wilhelm Boeddinghaus, system.de This presentation is available here: https://ripe84.ripe.net/wp-content/uploads/presentations/100-Boeddinghaus-R… Wilhelm did an in-depth analysis of how IPv6 is handled by the Windows 10 Defender Firewall software. The presentation conclusions provided some advice on how to best configure the firewall to provide good security for IPv6. Alvaro Vives, RIPE NCC, asked if there were improvements to the default firewall rules in Windows 11. Wilhelm said that he didn't think so, but he had not yet looked into Windows 11, and that he didn't expect the rules to be any better and maybe they should be proposed by the community. Christian Bretterhofer, Andritz AG, asked if there is a tool which allows users to see the firewall rules. Wilhelm replied that the Microsoft administration interface displays the rules. Most of the outgoing rules are not needed, because everything outgoing is allowed. He suggested that there might be some other firewall tools which were better. Kurt Kayser, Kurt Kayser Konsultation, commented that on the slides, the link local prefix was /64 and not /10. Wilhelm explained that this prefix size was mentioned in the Microsoft environments and simply took it over. Jan Zorz, 6connect, asked if Wilhelm thinks it's still a good idea to have a central firewall and not rely on the Windows 10 firewall. Wilhelm explained that you cannot rely on the Windows 10 firewall, but you must use it anyways. The central firewall does not protect your LAN. To ensure a secure environment, we need to use all the firewalls and packet filters available. Kostas Zorbadelos, CANAL+ Telecom, said that a default rule set is a problem, and asked Wilhelm if he had a suggestion for what the default ruleset should be. Wilhelm answered that it was difficult to come up with a real new default ruleset, because it is application centred. It depends on where the PC is used - in a loose environment or in a strict environment. Maybe the community can come up with a better firewall rule set. Maria Matejka, CZ.NIC, mentioned that one problem is a too-open firewall, and another is a too-closed firewall. The area of too closed and too open overlaps. We can't find a solution to having the firewall not too open and not too closed. Rule confirmations pop up frequently and home users click without thinking about it. Wilhelm replied that home users usually don't know much about packets and ports, so they don't understand what is right or wrong. Maybe the enterprise admins can make better rules for their environment, as they have the knowledge. Jen Linkova, Google, mentioned she is not a Windows user, but wondered if the firewall rules related to Neighbor Discovery might be useful for VMs on the same device. Wilhelm replied that he didn't think so. The VM packets don't need to be sent outside. Virtualisation is an enterprise feature and should be dealt with by the enterprise administrators. IPv6 Deployment Status: Update and Remaining Challenges Paolo Volpato, SID and Huawei Technologies This presentation is available here: https://ripe84.ripe.net/wp-content/uploads/presentations/114-IPv6_Status_Pa… Paolo presented on the status of IPv6 deployment around the world, pointing out how the statistics need a more refined interpretation to approach a true status. Christian Bretterhofer, Andritz AG, asked when companies in China would get access to IPv6 and open connectivity. His experience in China was difficult and the ISPs offered only a /64 IPv6 prefix. Paolo said that the plan was to have a good percentage of IPv6-only networks in China by 2030. He added that the issue of open connectivity could not be addressed in the current session. Maximilian Wilhelm, Cloudflare, commented that he felt IPv6 is a second-class citizen on Paolo's platform and asked when will IPv6 be on par with IPv4. Paolo answered that he is confident IPv6 is not a second-class citizen and if there is something to be fixed, he will pass on any messages to the headquarters for support. Jad el Cham, RIPE NCC, asked about IPv6 policies that have a good impact on IPv6 deployment. Paolo replied that certain policies in the USA have triggered some questions about IPv6 deployment. He added that his personal view was that the expectations are high and he doesn't believe that the proposed dates are realistic. Paolo suggested looking at countries like India, China, and Brazil, along with the EU. He expects that 2030 might be the flag year in which we might actually transition networks to IPv6. Maximilian Emig, aiticon GmbH, mentioned that Paolo's employer, Huawei, has been pushing the "New IP" proposal, which has received extensive press coverage. He asked Paolo to elaborate on how it fits with IPv6. Paolo mentioned he did not have an official answer. His personal opinion is it was a mistake, and it is not related to IPv6. Just Another Measurement of Extension Header Survivability (JAMES) Justin Lurman, ULiege, and Eric Vyncke, Cisco This presentation is available here: https://ripe84.ripe.net/wp-content/uploads/presentations/32-JAMES-RIPE84.pdf Justin Lurman provided an overview of how IPv6 packets using Extension Headers are processed or dropped on the public Internet. There were no questions or comments. IPv6 Addressing Inside a VPN Tunnel Between Endpoints With Rotating Prefixes Matthias Scheer, AVM This presentation is available here: https://ripe84.ripe.net/wp-content/uploads/presentations/59-ripe84_ipv6wg_v… Matthias Scheer presented on the challenges encountered by networks attempting to route IPv6 within VPNs, when the IPv6 prefixes assigned to the endpoints are rotated. Christian Betterhofer, Andritz AG, asked if there was any chance to update the Fritz 7582, specially the Wireguard support. Matthias replied that Wireguard support is available. He suggested to go to website and try out the beta, which is quite safe. Anže Jenšterle, AS211776, commented that Wireguard prefers IPv6 in DNS resolution only and this depends on how the resolver code is written. Jen Linkova, Google, mentioned that strictly speaking RFC 4193 does not recommend, it says certain addresses "CAN" be used. The language is not "SHOULD". Jen added that the default address selection is called "default" for a reason. Jan Zorz, 6connect, pointed out that Matthias mentioned the problem of rotating prefixes. Jan asked Matthias that if he came across ISPs that do this, he should point them to RIPE 690. Jan also mentioned that RFC 9096 talks about ways to improve the reaction of CPEs to IPv6 renumbering events. Gert Doering, congratulated AVM on working on IPv6 by default on their CPEs and on the work with IPv6 and VPNs. He mentioned that he liked the idea of using OSPFv3 to cope with renumbering events. Matthias remarked that he removed some slides that dealt with this topic due to time constraints. David Lamparter, OpenSourceRouting and NetDEF, replied to Jan Zorz's comment on RIPE 690 saying that he has customers that request prefix rotations. The RIPE document is not important for him. He applauded AVM's work on solving the prefix rotation problem. Matthias agreed that it was a good idea to continue the dialogue and find a solution together. Round Up and Thanks Working Group Co-Chairs The Working Group Co Chairs thanked the attendees for joining the session. For Internal Use Only

1 0

Join our Upcoming Open House on the IPv6 Skills Gap
by Alastair Strachan 14 Jun '22

14 Jun '22

Dear colleagues, We are organising an Open House on the IPv6 skills gap. The event will take place on Wednesday, 29 June from 10:00-11:30 UTC. Lack of adequate know-how remains a roadblock for IPv6 transition. Join us for a discussion on the challenges of building IPv6 skills. We'd love to hear your thoughts and suggestions! Register for free at: https://www.ripe.net/participate/forms/apply/openhouse-ipv6skills-29-june-2… <https://www.ripe.net/participate/forms/apply/openhouse-ipv6skills-29-june-2…> I hope to see many of you at there! Best regards, Alastair Strachan RIPE NCC Communtiy Development Officer

1 0

IPv6 Addressing Considerations (IETF Internet-Draft)
by Fernando Gont 02 Jun '22

02 Jun '22

Hi, We have published a revision of our IETF Internet-Draft "IPv6 Addressing Considerations". It is available at: https://datatracker.ietf.org/doc/html/draft-gont-v6ops-ipv6-addressing-cons… It discusses a lot of practical considerations regarding IPv6 addressing, so we'd love to hear from you if there's any that we missed or that you think we got wrong. Abstract IPv6 addresses can differ in a number of properties, such as scope, stability, and intended usage type. This document analyzes the impact of these properties on aspects such as security, privacy, interoperability, and network operations, with the goal of providing guidance about IPv6 address usage. Additionally, it identifies challenges and gaps that currently prevent systems and applications from leveraging the increased flexibility and availability of IPv6 addresses. Thanks! Regards, -- Fernando Gont SI6 Networks e-mail: fgont(a)si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

1 0

IPv6 Guide
by Jens Link 20 May '22

20 May '22

Hi, about a month ago I was asked on Twitter if I new any good and current books ob IPv6. Apparently there is nothing current[1]. I came up with the idea of starting an OpenSource Guide on IPv6. I created a git repo: https://gitlab.com/jenslink/ipv6guide and also have (sponsored) hardware to run website, mailing list, ... There is not much yet, but I'll reserved a couple of hours per week for it starting in June. The project is hosted in gitlab (because they have IPv6) and will be written in markdown. For now I'd prefer to start with an English version and maybe add translations later. All we need is people to create, review and edit content. That means we need your help if you have some time to spare. If you have any question, just ask. I'm also around the RIPE meeting for the rest of the week. Jens [1] Which might not be a problem, Gert Doering just recycled an 11year old presentation with very little changes. -- ---------------------------------------------------------------------------- | Delbrueckstr. 41 | 12051 Berlin, Germany | +49-151-18721264 | | http://blog.quux.de | jabber: jenslink(a)quux.de | --------------- | ----------------------------------------------------------------------------

6 11

Ipv6 adress policy Musings
by Jetten Raymond 18 May '22

18 May '22

Dear IPv6 list members. The Address policy working group has asked for our input on the current address policies. Please have a look at the large list of questions, and please do participate in the discussion on the Address Policy working group list https://www.ripe.net/ripe/mail/archives/address-policy-wg/2022-May/013541.h… Rgds The ipv6 wg co chairs For Internal Use Only

1 0

RIPE 84 IPv6 WG Agenda
by Jetten Raymond 11 May '22

11 May '22

Hello All, Here is the current agenda for the RIPE 84 meeting in Berlin next week (also online). The IPv6 WG session will be on Thursday 19 May 2022 from 11:00 - 12:30 CET Co Chairs, * welcome, etiquette etc, acceptation of the minutes 5 min. Wilhelm Boeddinghaus * "IPv6 and the Windows 10 Firewall" (25 min incl Q&A) Paolo Volpato * "IPv6 Deployment Status: Update and Remaining Challenges". (20 min incl Q&A) Justin Lurman & Eric Vyncke * "Just Another Measurement of Extension header Survivability (JAMES)" (10 min incl Q&A) Eric van Uden Or collegue * IPv6 in the field Feld, KPI-results / and Or naming challenges IPv6 inside VPN (25 min incl Q&A) Co Chairs * round up, thanks 5 min Welcome onsite, or online ! Raymond Jetten Senior Technology Specialist Production Cloud Services, Networks and connectivity Interconnectivity & Content Elisa Oyj Vuolteenkatu 2 33100 Tampere +358 45 6700 139 raymond.jetten(a)elisa.fi<mailto:raymond.jetten@elisa.fi> www.elisa.fi<http://www.elisa.fi/> Lisätietoa henkilötietojen käsittelystä ja tietosuojasta Elisalla https://elisa.fi/tietosuoja Mer information om Elisas hantering av personuppgifter och dataskydd https://elisa.fi/tietosuoja More information on personal data management and data protection at Elisa https://elisa.com/dataprotection ********************************************************************************************* For Internal Use Only

1 0

Second call for presentations IPv6 WG @RIPE84
by Jetten Raymond 12 Apr '22

12 Apr '22

Hello All, RIPE 84 will take place from 16-20 May 2022 in a hybrid format in which online and onsite participants can interact with each other using a common platform. The onsite event will take place in Berlin. For both cases you can register here: https://ripe84.ripe.net/attend/register/ The IPv6 Working Group session is scheduled for , Thursday 19 May from 11:00 . 12:30 (UTC+1) We still have some time in our session. We are looking for presentations - please email : ipv6-wg-chair (at) ripe.net if you'd like to present. Please also state if you intend to be online or onsite, and the duration of your presentation, and a short description of it. Once we have decided on the agenda, we'll contact the presenters. Hope to see many of you, On behalf of the IPv6-WG Benedikt, Jen, Ray

1 0

Last call and final reminder for nominations to the 2022 Rob Blokzijl Award
by Carsten Schiefner 14 Mar '22

14 Mar '22

[Apologies for cross-posting to various RIPE lists] Dear IPv6 WG members - this is the last call and final reminder for nominations to the 2022 Rob Blokzijl Award that will be accepted until this Friday, 18th March, at 23:59 UTC. In seeking nominations for this prestigious award, which was created to celebrate Rob's contributions to the development of the Internet, the Award Committee (https://rob-blokzijl-foundation.org/2021/11/22/2022-award-committee/) is interested to receive nominations of those who have reflected Rob's approach in either a technical or operational capacity. Please give some consideration to nominating individuals - but also teams and groups of people! - in your own community and/or the wider industry in the RIPE region who, in your opinion, deserve to be recognised for their work to make the internet and/or internet community better. To specifically have this emphasised again after some according queries: nominations of teams and groups of people are very well possible and wished for as well in case their collective work would match the criteria of the call as laid out! The Award Committee is particularly interested to receive nominations of contributors who, in addition to their own contributions, have also supported and enabled others anywhere in the world. Also, the Award Committee would like to encourage those making nominations to consider not only the community members in the later stages of their careers or who are widely known but also those who may have contributed greatly in the springtime of their career or discreetly for the greater good or who may be considered to be part of an unrepresented group. And last but not least: those of you who previously have made a nomination other than Wilfried Woeber, the 2018 awardee, may want to consider resubmitting a nomination. The complete details of the call and the nomination process can be found at: https://rob-blokzijl-foundation.org/2021/11/25/call-for-nominations-2022/ Best wishes and kind regards Carsten (on behalf of the Award Committee)

1 0