- ipv6-wg - mailman.ripe.net

Call for presentations IPv6 WG @RIPE86
by Raymond Jetten 27 Mar '23

27 Mar '23

Hello All, RIPE 86 will take place from 22-26 May 2023 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 Rotterdam, Netherlands. For both cases you can register here: https://ripe86.ripe.net/attend/register/ The IPv6 Working Group session is scheduled for Thursday 25 May from 11:00 . 12:30 (UTC+1) (however it still may change) 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 2

(IETF I-D): Implications of IPv6 Addressing on Security Operations (Fwd: New Version Notification for draft-gont-opsec-ipv6-addressing-00.txt)
by Fernando Gont 05 Feb '23

05 Feb '23

Hi, All, Recently, I happened to participate in an IPv6 deployment meeting with some large content provider, and said meeting included a discussion about how to mitigate some attacks using block-lists. These folks argued that they ban offending IPv6 addresses as /128s, following IPv4 practices. So it seemed to me that some of the implications arising from the increased IPv6 address space were non-obvious to them. -- that has been the motivation for the publication of this document. * TXT: https://www.ietf.org/archive/id/draft-gont-opsec-ipv6-addressing-00.txt * HTML: https://www.ietf.org/archive/id/draft-gont-opsec-ipv6-addressing-00.html Comments welcome! P.S.: The document is targeted at the IETF opsec wg (https://www.ietf.org/mailman/listinfo/opsec), but I'll be happy to discuss it on this mailing-list, off-list, or at the opsec wg mailing-list... Thanks! Regards, Fernando -------- Forwarded Message -------- Subject: New Version Notification for draft-gont-opsec-ipv6-addressing-00.txt Date: Thu, 02 Feb 2023 19:48:40 -0800 From: internet-drafts(a)ietf.org To: Fernando Gont <fgont(a)si6networks.com>, Guillermo Gont <ggont(a)si6networks.com> A new version of I-D, draft-gont-opsec-ipv6-addressing-00.txt has been successfully submitted by Fernando Gont and posted to the IETF repository. Name: draft-gont-opsec-ipv6-addressing Revision: 00 Title: Implications of IPv6 Addressing on Security Operations Document date: 2023-02-02 Group: Individual Submission Pages: 8 URL: https://www.ietf.org/archive/id/draft-gont-opsec-ipv6-addressing-00.txt Status: https://datatracker.ietf.org/doc/draft-gont-opsec-ipv6-addressing/ Htmlized: https://datatracker.ietf.org/doc/html/draft-gont-opsec-ipv6-addressing Abstract: The increased address availability provided by IPv6 has concrete implications on security operations. This document discusses such implications, and sheds some light on how existing security operations techniques and procedures might need to be modified accommodate the increased IPv6 address availability. The IETF Secretariat

1 0

New on RIPE Labs: IPv6 Policy Is a Community Self-Governance Success Story
by Alun Davies 30 Jan '23

30 Jan '23

Dear colleagues, The RIPE Address Policy Working Group invites the community to join the conversation on the next phase of IPv6 policy. In this new article on RIPE Labs, Leo Vegoda talks about the success of the policy so far and the process that is underway in order to determine whether there’s need for change: https://labs.ripe.net/author/leo_vegoda/ipv6-policy-is-a-community-self-gov… Best regards, Alun Davies RIPE Labs Editor RIPE NCC

1 0

Pv6 policy - prioritisation and outcomes discussion webinar
by Raymond Jetten 27 Jan '23

27 Jan '23

Dear IPv6-WG list members, Below an invite from the Address Policy Working Group, to an IPv6 address policy webinar. Kind regards, Ray From: Leo Vegoda <leo(a)vegoda.org> Date: Thu, 26 Jan 2023 at 10:14 Subject: IPv6 policy - prioritisation and outcomes discussion webinar To: <address-policy-wg(a)ripe.net> At RIPE 85 we continued a review of the IPv6 policy that began at RIPE 83. Several areas for improvement were agreed. We promised to host an inter-sessional webinar to discuss priorities and the outcomes to work towards. The identified areas for improvement include: - Better guidance on documentation requirements for large allocations - Simpler language for the HD-ratio - Make it easier for small networks to assign a few addresses to other organisations - Ensure allocations always fall on a nibble boundary If you wants to help us set priorities and define the outcomes the community needs you are welcome to join. Monday, 20 February 2023 at 13:00 UTC (14:00 CET). Join Zoom Meeting https://ripe.zoom.us/j/94307989734?pwd=YytnQm53SjJEWUtKemxQM3dGcjZmQT09 Meeting ID: 943 0798 9734 Passcode: 339420 Leo Vegoda for the Address Policy WG co-chairs For Internal Use Only

1 0

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 18 Jan '23

18 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