- ipv6-wg - mailman.ripe.net

Experiences with IPv6-only MX as primary?
by Shane Kerr 11 Jun '18

11 Jun '18

Hello, I set up a mail server zone to have an IPv6-only primary and a dual-protocol secondary, like this: ; SMTP chooses lower-priority first, so smtp-primary is preferred example.com. 300 MX 10 smtp-primary.example.com. example.com. 300 MX 100 smtp-secondary.example.com. ; smtp-primary is IPv6-only smtp-primary.example.com. 300 AAAA 2001:DB8::1 ; smtp-secondary has both IPv6 and IPv4 addresses smtp-secondary.example.com. 300 AAAA 2001:DB8::2 smtp-secondary.example.com. 300 A 192.0.2.11 Mail delivery via IPv6 works fine (as you would expect), and mail delivery from some IPv4-only servers also works fine (as I think the standards dictate). My concern is that some mail servers may choke on this setup. For example, http://mailtester.com complains "Network is unreachable". Of course, I also worry about all the spammers who may not be able to deliver because of incomplete mail implementations on the trojans and other viruses infecting their zombie hosts. 😉 Does anyone have any experience with a similar setup? Have there been problems? Cheers, -- Shane

2 1

Celebrating the Anniversary of World IPv6 Launch on RIPE Labs
by Mirjam Kuehne 07 Jun '18

07 Jun '18

Dear colleagues, We've been celebrating the sixth anniversary of the World IPv6 Launch with an RIPE NCC::Educa IPv6 Day event and a series of IPv6-related articles on RIPE Labs. Blockers to IPv6 and How to Overcome Them: https://labs.ripe.net/Members/david_holder/blockers-to-ipv6-adoption Celebrating IPv6 Launchiversary: A View from RIPE Atlas and K-root: https://labs.ripe.net/Members/stephen_strowes/ipv6-launchiversary-a-review-… So Long and Thanks for All the IPv6 (an article on the dissolution of the Dutch IPv6 Task Force): https://labs.ripe.net/Members/marco_hogewoning/so-long-and-thanks-for-all-t… RIPE NCC::Educa IPv6 Day (and the RIPE NCC's perspective on IPv6 deployment): https://labs.ripe.net/Members/ulka_athale_1/ripe-ncc-educa-ipv6-day Happy reading :-) Kind regards, Mirjam Kühne RIPE NCC

1 0

Y.IPv6RefModel is out of scope for the ITU
by Nick Hilliard 31 May '18

31 May '18

JORDI PALET MARTINEZ via ipv6-wg wrote on 26/05/2018 12:16: > I already said this before, but "... in running such networks vis > [via] the RIR policy making fora." is wrong. Stepping back a bit, what we're discussing here is not whether address assignment / allocation models should be dealt with by the RIRs or the IETF, but whether they are in scope for the ITU. The answer to this is that all aspects of IP number resource management are resoundingly out of scope for the ITU. This includes all IP number resource assignment and allocation issues, all addressing models, and by direct implication, the SG20 work on the Y.IPv6RefModel work item. There needs to be a crystal clear statement from the RIR community that this entire exercise is wildly out of scope for the ITU, that SG20 needs to cease and desist from reaching into areas outside their competence, and that the Y.IPv6RefModel work item needs to end, immediately and permanently. Nick

6 7

comments on Y.Pv6RefModel
by Jim Reid 26 May '18

26 May '18

I lurk on this list. However I have to say something about this document, mostly because of what’s happening at ITU SG20. It’s taken a lot of work by Marco and others to persuade SG20 to engage with RIPE. And it’s important that we respond clearly. I just have three things to say. 1) The document is very poor. [I’m being uncharacteristically diplomatic.] It contains lots of errors. The proposed addressing plans are just wrong. It would be a *huge* mistake for anyone to adopt these and much, much worse if SG20 recommends them for global adoption. SG20 should abandon this fundamentally flawed document. Work on it simply has to stop. 2) IP addressing plans for IoT devices can’t and shouldn’t be discussed in isolation. They have to be developed in the context/circumstances of the networks where these devices will be used: ie alongside everything else that’s using or will be using the Internet. If members of SG20 have ideas on IP addressing plans, they are more than welcome to come to the RIR fora where their suggestions can be discussed/analysed and possibly incorporated into RIR address policy. That work can’t and shouldn’t take place at SG20. Or elsewhere in the ITU. 3) It’s unacceptable for the ITU to even attempt to get involved in IP addressing. It’s out of scope. They should stick to co-ordination of E.164 numbers and X.25 addresses. IP addressing is primarily a matter for the RIRs. And other Internet-related fora like RIPE, NANOG, IETF, etc. There’s no role for the ITU in this at all.

5 9

Re: [ipv6-wg] comments on Y.Pv6RefModel
by Willy MANGA 25 May '18

25 May '18

Hi, > Message: 1 > Date: Fri, 25 May 2018 10:07:13 +0100 > From: Jim Reid <jim(a)rfc1035.com> >[...] > 3) It?s unacceptable for the ITU to even attempt to get involved in IP addressing. It?s out of scope. They should stick to co-ordination of E.164 numbers and X.25 addresses. IP addressing is primarily a matter for the RIRs. And other Internet-related fora like RIPE, NANOG, IETF, etc. There?s no role for the ITU in this at all. maybe a coordonnated letter from NRO (or ICANN), ISOC which explained *diplomatically* that IP addressing is a matter of RIRs :) -- Willy Manga @ongolaboy https://ongola.blogspot.com/

1 0

itu document on ipv6 addressing for iot
by James Morrow 25 May '18

25 May '18

i read this document with a mixture of astonishment, confusion and horror. it's awful. the document is utterly, utterly broken. it has no redeeming or worthwhile qualities at all. the only thing it's good for is an example of how #not# to do an ip addressing plan based on errors and poorly articulated, mistaken assumptions. it also shows beyond any doubt that itu should not meddle in ip addressing because it has no competence or mandate to get involved in this field. i've already seen far too many deeply flawed itu documents on ipv6, such as the 2009? nav6 study. this one's much, much worse. it's painfully obvious whoever wrote this junk has no understanding and operational experience of how to design or deploy an ipv6 addressing plan for any non-trivial ipv6 network. the document is not a sound piece of work that makes any sort of technical or engineering sense. the document is riddled with errors - far too many to list. it makes ridiculous assertions that have no basis in fact and does not provide any references to justify these claims or let someone check them. i started to write down these flaws and then gave up in disgust. why should i do somebody else's homework for them? conflating ipv6 uptake rates with developed/developing countries is yet another serious failing. these things are completely orthogonal to each other. the unstated assumptions are wrong too. first of all, the notion of "special" ipv6 addressing plans for iot devices is foolish. these don't need to be treated differently and shouldn't be treated differently from anything else that's connected to the internet - at least from an addressing perspective. next, it's beyond absurd to suggest or imply there could be one over-arching addressing plan that can be used and will work perfectly for iot devices in any network or every use case. that's just basic common sense. how you'd do that depends on the actual network and its requirements. for example take smart lightbulbs: an addressing plan for home use wouldn't be suitable for a large building (school, hospital, office block, etc) or for a town's street lights. they'd all have different (subnet) addressing plans that were suited to their specific needs - number of lights, topology, security, planned expansion, architecture(s), link-layer connectivity, redundancy / spofs, budget, latency, bandwidth, interoperability and compatibility with existing systems / networks (if any), access controls and so on. the document doesn't even hint at any of those considerations. the only thing to be done with this document is kill it. kill it with fire. it's too far gone to be fixed or salvaged.. imo, the wg needs to tell itu to stay well away from ip addressing and leave this to the experts who actually build and run ip networks.

3 4

Still open for discussion: Invitation to supply feedback on ITU draft Recommendation on IPv6 address planning for IoT
by Jetten Raymond 24 May '18

24 May '18

Hello All, We are happy to announce that ITU Study Group 20 has responded positively to our offer and have decided to share the current working draft with us, for the purpose of review and for RIPE community to provide feedback. As it is quite big, the text of this draft Recommendation Y.IPv6RefModel "Reference model of IPv6 subnet addressing plan for Internet of things deployment" has been made available on the IPv6 WG pages: https://www.ripe.net/participate/ripe/wg/ipv6/documents/itu-ipv6refmodel We kindly invite you to provide feedback and comments on the contents of this document via this mailing list or of course the RIPE Forum web interface. The RIPE NCC has agreed to ensure that the comments will be collected and made available to the ITU via response to the Liaison Statement below. We of course also hope to discuss the feedback with the editor of the document during our second session at RIPE 76. Regards, Benedikt, Jen, Raymond Liaison Statement we received from ITU Study Group 20 in response to our invite: > ITU-T Study Group 20 Q3/20 thanks the RIPE NCC for their contribution that contained the invitation from the RIPE IPv6 Working Group. We thank the RIPE IPv6 Working Group for the invitation to present Draft Recommendation ITU-T Y.IPv6RefModel at the May 2018 RIPE meeting for the purpose of obtaining operational feedback and input. We are delighted to recognize the invitation from RIPE and confirm it is the intention of the editor of the Draft Recommendation ITU-T Y.IPv6RefModel to participate in the RIPE meeting in May 2018. > > Attached is a copy of the draft Recommendation. We look forward to the feedback and comments from the RIPE community. For Internal Use Only

4 3

Re: [ipv6-wg] Invitation to supply feedback on ITU draft Recommendation on IPv6 address planning for IoT
by Patrik Fältström 24 May '18

24 May '18

Hi, FWIW, I spent some time going through Y.IPv6RefModel and really really want RIPE NCC to be strong and blunt in their answer. The short response is clearly what Jordi wrote: > In short the document makes no sense at all and is plenty of errors even in the way some notation, protocol names and references are used. The slightly longer response is that there are a number of explicit misunderstandings in the document, and they are not small misunderstandings. They will (not might) create operational issues if implemented as explained. Let me give a few examples: 1. Transition from IPv4 to IPv6 The whole document includes in a number of cases statements that claim transmission from IPv4 to IPv6 is easier if there is a mechanical mapping between the addresses in the two protocols. This is wrong in so many ways. First of all that there is a transition. What is happening is that IPv6 is deployed. Then one day maybe IPv4 is depleted, or rather, made less important. Sure, various applications with move from using IPv4 to using IPv6, but having application layer transition their default protocol has not much or anything to do with the address plan. Further, due to the limited number of IPv4 addresses, the subletting (if any) in IPv4 space is constrained in a way that IPv6 do not have to be. Limiting IPv6 address plans to the same scheme we have been squeezed into for IPv4 is a bad idea from the beginning. Its like adding ICT to existing processes instead of reviewing and optimizing processes the way possible thanks to ICT. This is mentioned in for example the Summary, Section 10, 11, 12.1, 12.2, 12.3, 12.4 and more. 2. Consultation with IETF It is claimed in the Summary that Y.IPv6RefModel have been developed in coordination with IETF. This without any reference to any discussion, Internet-Draft or such. 3. Deployment of IPv6 There is a claim in Section 7 that IPv6 might be the advent of a new Digital Divide. Some countries are mentioned as having high deployment of IPv6 and others very low. The examples are clearly chosen to strengthen the argument as development countries with low IPv6 deployment (Sweden for example) are not mentioned. Further, in Section 8 where large scale deployment of IPv6 is mentioned, China is listed as a clear winner, although China is not listed as an exception when exceptions are listed in Section 7. In short, having such statistics and drawing conclusions from it in such broad strokes with the brush is just a stupid idea, imflammatory and creates unnecessary discussion. If the document is good from a technical grounds it should be able to stand on its own for such reasons. 4. Reference Model for IPv6 deployment There is a claim in Section 7 that having a reference model for how to subnet end users allocations developed in the ITU-T, and this specific model, will address issues regarding Digital Divide. As the earlier portion of Section 7 and arguments in other places in the document is at best weak, if not wrong, making claims based on this is not possible. Further, there are no examples or arguments why the reference model explained would help with solving the low IPv6 deployment in for example Sweden. 5. Reference Model for IoT deployment In Section 8 it is claimed this model should be particularly interesting for large scale IoT deployments but also IoT deployments. As IoT devices are connected to the Internet like any Internet Connected Device there is no difference between IoT deployment and non-IoT deployment. The contrary. We will have IoT deployment everywhere. In every house, home, car, owen, airplane, ship, watch we will have some IoT devices or IoT functionality. Having specific IoT reference models and then non-IoT allocation models as well will absolutely create a digital divide and fragmentation of the Internet. If any reference model is to be created (or Best Practice) it must be created from the general use of IPv6 in the world, and not for IoT specifically. 6. Explicit mapping between geographical location and addresses In Section 11 there is a requirement that the geographical location of a device is to be visible as a specific set of bits (the first four). This implies a device is changing IPv6 address when being moved from one building to another, and that one can not have a subnet covering more than 16 buildings. I do not give more comments on this. 7. DMZ Section 11 talks about DMZ in singular. This is built upon the thinking used in the 20th century that one have a firewall (i.e. one firewall) that separates the "inside" from the "outside" and that everything on the "inside" of the firewall was secure, safe and trusted. And further, that devices that where to be reached from the outside had to be in a so called DMZ. This is a model that no longer is valid. All devices and services should not be reachable, and this can not be based on some firewall. Every active network element that can filter traffic must do so, and the devices themselves must filter explicitly what services they expose and make available. And this independently of whether it is on the "inside" or "outside" of whatever layer in the layered protection designed in the network. 8. Internal servers Similarly to the misunderstanding of network design described in (7) above also the concept of "internal server" is confusing. Today network structure consists of various services being exposed from various virtual and otherwise existing processes that announce themselves to clients. Various discovery mechanisms exists for such services, and the existence of dynamic allocation of services, failover mechanisms etc existing in todays architectures makes discussion of "server" on the IP addressing layer feel like discussions on how to move a rune stone in the most optimal way. 9. Proposed addressing schemes Based on the above and more, the proposed models in section 12 are just wrong. If, and this is a big if, some coordination is to be created regarding best practices regarding address management of whatever is allocated to the end user, that obviously must be developed in the IETF, or possibly, the RIR community (or a mix between the two -- as normal). The IETF and RIR communities must in this specific case be clear and crisp in the response to the ITU-T that having ITU-T injecting themselves in matters like this is stepping too far into the area where other SDOs are responsible for. paf

1 0

New on RIPE Labs: What Drives IPv6 Deployment?
by Mirjam Kuehne 23 May '18

23 May '18

Dear colleagues, For those of you who missed Geoff Huston's presentation at RIPE 76, it is now on RIPE Labs: What Drives IPv6 Deployment? https://labs.ripe.net/Members/gih/what-drives-ipv6-deployment Kind regards, Mirjam Kühne RIPE NCC

1 0

New on RIPE Labs: Conditional Router Advertisements in Enterprise Multihoming
by Mirjam Kuehne 22 May '18

22 May '18

Dear colleagues, For those of you who were not at the IPv6 WG meeting at RIPE 76 last week, here is Jen Linkova's article on "Conditional Router Advertisements in Enterprise Multihoming": https://labs.ripe.net/Members/jen_linkova/conditional-router-advertisements… Kind regards, Mirjam Kühne RIPE NCC

1 0

slides about transition tutorial and comparison among mechanisms
by JORDI PALET MARTINEZ 17 May '18

17 May '18

Hi all, As mention in the meeting today, here is the link to the latest tutorial that I did 2 weeks ago in the LACNIC meeting (slides are in English), including a comparison among all the transition mechanisms. http://www.lacnic.net/innovaportal/file/2621/1/ipv6-trans-and-ipv6-only_v8.… Look for the "summary" comparison at slide number 57. Regards, Jordi ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

1 0

Chair election
by Jen Linkova 13 May '18

13 May '18

Hello, Wow, it's been 3.5 years already since I joined IPv6 WG chairs club ;) As per our current policy [1] it's time for me to step down. Fortunately for me, that policy does allow me to stand for re-election, so I'd love to serve another term as IPv6 WG co-chair if the group believes it's a good idea ;) See you all in Marseilles! [1] https://www.ripe.net/participate/ripe/wg/ipv6/ipv6-wg-chair-selection-proce… -- SY, Jen Linkova aka Furry

14 13

Re: [ipv6-wg] budgetkonto Henrik Kramshøj 2724291 tilpasning
by Henrik Lund Kramshøj 09 May '18

09 May '18

On Tue, 8 May 2018 14:23:15 +0000 Lise-Lotte Sørensen <liselotte.sorensen(a)nordjyskebank.dk> wrote: > Hej Henrik Hej igen > > Jeg har slettet Børnefonden og nedsat indbetalingen i forhold hertil. > Nyt skema er lagt i e-arkiv. > > Der er betalt kr. 6.232,87 den 7/6 2017, 8.821,71 den 7/9 2018, kr. > 6.505,18 den 7/12 og kr. 6.591,74 til henholdsvis DONG/Ørsted, så > derfor er udgiften sat til kr. 6.600 hvert kvartal. Kan vi se, hvad > opgørelsen viser til juni, inden vi retter beløbet ned ? Ja det kan vi da. Det er godt at få ryddet lidt op, og tak for hjælpen. -- Mvh/Best regards Henrik Lund Kramshøj, Follower of the Great Way of Unix internet samurai cand.scient CISSP hlk(a)kramse.org hlk(a)zencurity.dk +45 2026 6000

1 0

IPv6 WG Agenda (RIPE76)
by Jen Linkova 07 May '18

07 May '18

Hello, The draft agenda for Ipv6 WG sessions at RIPE76 has been published: https://ripe76.ripe.net/programme/meeting-plan/ipv6-wg/ -- SY, Jen Linkova aka Furry on behalf of IPv6 WG chairs.

3 3

RIPE75 IPv6 WG meeting minutes
by Jen Linkova 11 Apr '18

11 Apr '18

Hello, Just in time for RIPE76...;) Meeting minutes from RIPE75 IPv6 WG sessions are posted at RIPE website: https://www.ripe.net/participate/ripe/wg/ipv6/minutes/ipv6-working-group-mi… If you said anything at the mic during those sessions, please review and let us know if any correction is required! Thanks! -- SY, Jen Linkova aka Furry

1 0

New on RIP Labs: Persistent DHCPv6 Prefix Delegation at GavleNet
by Mirjam Kuehne 10 Apr '18

10 Apr '18

Dear colleagues, Read on RIPE Labs how Torbjorn Eklov helped municipalities in Sweden to deploy IPv6. In this second part he discusses how they used persistent DHCPv6 prefix delegation: https://labs.ripe.net/Members/teklov/static-dhcpv6-prefix-delegation Kind regards, Mirjam Kühne RIPE NCC

1 0

New on RIPE Labs: Connecting 5 Million Users to IPv6
by Mirjam Kuehne 04 Apr '18

04 Apr '18

Dear colleagues, Richard Patterson, Senior Network Design Engineer at Sky UK, describes on RIPE Labs how they connected 5 million users to IPv6: https://labs.ripe.net/Members/richard_patterson/connecting-5-million-users-… Kind regards, Mirjam Kühne RIPE NCC

1 0

New on RIPE Labs: The Avans Academy - Top of the Class in IPv6 Usage in the Netherlands
by Mirjam Kuehne 02 Feb '18

02 Feb '18

Dear colleagues, We met with the IPv6 team at the University of Applied Sciences in Breda, The Netherlands, and talked to them about the steps they took to deploy IPv6 in their network. Please find more details on RIPE Labs: https://labs.ripe.net/Members/nathalie_nathalie/the-avans-academy-top-of-th… Kind regards, Mirjam Kühne RIPE NCC

1 0

Call for presentations for the IPv6 Workgroup at RIPE76
by Jetten Raymond 02 Feb '18

02 Feb '18

Dear IPv6 WG list members, RIPE76 is coming up and its time again to grab your chances to present at the IPv6 working group, which will be on Wednesday 16 May 2018, in Palais du Pharo, Marseille, France. If you have a presentation or a topic that would be of great interest to the IPv6 WG, which unfortunately only has 1 timeslot this time, please inform the WG chairs on this. Send your presentation or explain the contents to ipv6-wg-chairs(a)ripe.net<mailto:ipv6-wg-chairs@ripe.net>. Rgds, Benedikt, Jen, Ray. For Internal Use Only

1 0

New on RIPE Labs: IPv6 Flow Label: Misuse in Hashing
by Mirjam Kuehne 12 Jan '18

12 Jan '18

Dear colleagues, Please read this new article by Joel Jaeggli on RIPE Labs: IPv6 Flow Label: Misuse in Hashing https://labs.ripe.net/Members/joel_jaeggli/ipv6-flow-label-misuse-in-hashing Kind regards, Mirjam Kühne RIPE NCC

1 0

New on RIPE Labs: How to Run and Protect an Email Server on IPv6
by Mirjam Kuehne 08 Jan '18

08 Jan '18

Dear colleagues, A new RIPE Best Current Operational Practices document is in the making. Please contribute your expertise! For more details, please read this short RIPE Labs article by Jan Zorz: https://labs.ripe.net/Members/JanZorz/how-to-run-and-protect-an-email-serve… Kind regards, Mirjam Kühne RIPE NCC

1 0

New on RIPE Labs: IPv6 in Enterprise Client Networks
by Mirjam Kuehne 04 Jan '18

04 Jan '18

Dear colleagues, A Happy New Year to you all! The first RIPE Labs article in 2018 explains how to deploy IPv6 in enterprise networks: IPv6 in Enterprise Client Networks by Wilhelm Boeddinghaus https://labs.ripe.net/Members/wilhelm_boeddinghaus/ipv6-in-enterprise-clien… Kind regards, Mirjam Kühne RIPE NCC

1 0

DMARC Solution Applied to this Mailing List
by Adam Castle 18 Dec '17

18 Dec '17

Dear Working Group, As more email providers enable Domain Message Authentication Reporting & Conformance (DMARC), some people find they can no longer receive emails from the mailing lists they are subscribed to. We have deployed a Mailman setting change to address this problem. After consultation with the RIPE Working Group Chairs, we have enabled the DMARC "Munge From" setting on all RIPE mailing lists. This means that if your email service provider has DMARC enabled, you will continue to receive all emails sent to this mailing list, but the "From" part of the header will change. If you don't have DMARC enabled, you won't see any change to the emails you receive from this mailing list. You can find more information about how we have been handling DMARC in the following RIPE Labs articles: https://labs.ripe.net/Members/adam_castle/dmarc-and-the-ripe-ncc https://labs.ripe.net/Members/adam_castle/ripe-mailing-lists-and-dmarc To ensure all working group participants are aware of the changes, I am sending this mail to all working groups. If you have any questions or encounter any issues on this mailing list, please let me know. Many thanks. Adam Castle Web Services Manager RIPE NCC

1 0

New on RIPE Labs: Let's talk about RFC 6980
by Mirjam Kuehne 13 Dec '17

13 Dec '17

Dear colleagues, This RIPE Labs article by Jacky Hammer covers the topic of whether different operating systems have correctly implemented RFC 6980 (Security Implications of IPv6 Fragmentation with IPv6 Neighbor Discovery): https://labs.ripe.net/Members/jacky_hammer/lets-talk-about-rfc-6980 Kind regards, Mirjam Kühne RIPE NCC

1 0

New on RIPE Labs: IPv6 Addresses, Security and Privacy
by Mirjam Kuehne 08 Dec '17

08 Dec '17

Dear colleagues, The choice of the IPv6 address format impacts a host's security and privacy. This new RIPE Labs article by Johanna Ullrich discusses this impact, highlights how current address formats deal with matters of security and privacy, and pinpoints shortcomings in today's addressing mechanisms: https://labs.ripe.net/Members/johanna_ullrich/ipv6-addresses-security-and-p… Kind regards, Mirjam Kühne RIPE NCC

1 0