Folks,
It is often argued that IPv4 practices should be forgotten when
deploying IPv6, as after all IPv6 is a different protocol! But we think
years of IPv4 operational experience should be leveraged as much as
possible.
So we are publishing IPv6 Security for IPv4 Engineers as a roadmap to
IPv6 security that is specifically aimed at IPv4 engineers and operators.
Rather than describing IPv6 in an isolated manner, it aims to re-use as
much of the existing IPv4 knowledge and experience as possible, by
highlighting the security issues that affect both protocols in the same
manner, and those that are new or different for the IPv6 protocol suite.
Additionally, it discusses the security implications arising from the
co-existence of the IPv6 and IPv4 protocols.
The document is available at:
https://www.internetsociety.org/blog/2019/03/ipv6-security-for-ipv4-enginee…
Comments are welcome. And if you think we've missed something or
the like, please drop me en email -- the document can always be revised.
P.S.: If you haven't taken a look at it (yet), we have also published
the "IPv6 Security Frequently Asked Questions (FAQ)" at:
https://www.internetsociety.org/blog/2019/02/ipv6-security-faq
Thanks!
Cheers,
--
Fernando Gont
SI6 Networks
e-mail: fgont(a)si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
Hello,
this is the first time I write in this mailing list.
I have a question for you.
I'm working for an ISP that obtained IPv4 (/22) and IPv6 (/29). I would like to use IPv6. Could you suggest me some documents and some manuals useful to implement IPv6, but avoiding problems for our customers?
In particular, I would like to avoid compatibility problems with VoIP PBXs, network printers, alarm systems, etc ...
In Italy only few ISPs provide IPv6 addresses and we would like to try to reverse this negative trend compared to the rest of Europe.
I hope you can help me understanding the advantages and opportunities in investing in the direction of IPv6.
Kind regards
Alessandro
Alessandro Valenza
Ufficio TLC
Tel: 0571 1738257
Fax: 0571542536
www.enegan.it
CONFIDENZIALITÀ
Questo messaggio, inclusi gli eventuali allegati, è indirizzato solo ai destinatari e può contenere informazioni riservate
e confidenziali. Se avete ricevuto il messaggio senza esserne un destinatario, o un suo rappresentante autorizzato, la
presente comunicazione vale come formale divieto di diffusione del contenuto del messaggio.Se avete ricevuto il messaggio
per errore, siete pregati di cancellarlo, assieme a tutti gli allegati, dal vostro sistema e di informare
immediatamente il mittente.
Hi Alessandro,
I will suggest to for IPv6-only with IPv4-as-a-Service. I’m right now doing this deployment with 464XLAT for a customer this week, including wired and cellular access.
You can find the slides of my last tutorial in the RIPE meeting at:
https://ripe77.ripe.net/programme/meeting-plan/tutorials/
I guess there is a video as well, otherwise, I did a similar tutorial (even with hands-on in this case, total 3 hours) in the last APNIC (just two weeks ago) that you can search for.
Regards,
Jordi
De: ipv6-wg <ipv6-wg-bounces(a)ripe.net> en nombre de Alessandro Valenza <a.valenza(a)enegan.it>
Fecha: lunes, 11 de marzo de 2019, 17:41
Para: "ipv6-wg(a)ripe.net" <ipv6-wg(a)ripe.net>
Asunto: [ipv6-wg] IPv6 Implementation for an ISP
Hello,
this is the first time I write in this mailing list.
I have a question for you.
I’m working for an ISP that obtained IPv4 (/22) and IPv6 (/29). I would like to use IPv6. Could you suggest me some documents and some manuals useful to implement IPv6, but avoiding problems for our customers?
In particular, I would like to avoid compatibility problems with VoIP PBXs, network printers, alarm systems, etc ...
In Italy only few ISPs provide IPv6 addresses and we would like to try to reverse this negative trend compared to the rest of Europe.
I hope you can help me understanding the advantages and opportunities in investing in the direction of IPv6.
Kind regards
Alessandro
Alessandro Valenza
Ufficio TLC
Tel: 0571 1738257
Fax: 0571542536
www.enegan.it
CONFIDENZIALITÀ
Questo messaggio, inclusi gli eventuali allegati, è indirizzato solo ai destinatari e può contenere informazioni riservate
e confidenziali. Se avete ricevuto il messaggio senza esserne un destinatario, o un suo rappresentante autorizzato, la
presente comunicazione vale come formale divieto di diffusione del contenuto del messaggio.Se avete ricevuto il messaggio
per errore, siete pregati di cancellarlo, assieme a tutti gli allegati, dal vostro sistema e di informare
immediatamente il mittente.
**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
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.
Folks,
If you follow the 6man working group of the IETF you may have seen a
bunch of emails on this topic, on a thread resulting from an IETF
Internet-Draft we published with Jan Žorž about "Reaction of Stateless
Address Autoconfiguration (SLAAC) to Renumbering Events" (Available at:
https://github.com/fgont/draft-slaac-renum/raw/master/draft-gont-6man-slaac…
)
Short version of story:
There are a number of scenarios where SLAAC hosts may end up using stale
configuration information.
For example, a typical IPv6 deployment scenario is that in which a CPE
router requests an IPv6 prefix to an ISP via DHCPv6-PD, and advertises a
sub-prefix of of the leased prefix on the LAN-side, via SLAAC. In such
scenarios, if the CPE router crashes and reboots, it may loose all
information about the previously-leased prefix. Upon reboot, the CPE
router may be leased a new prefix that will result in a new sub-prefix
being advertised on the LAN-side of the CPE router.
As a result, hosts will normally configure addresses for the
newly-advertised prefix, but will normally also keep (and use) the
previously-configured (and now stale!) IPv6 addresses, leading to
interoperability problems.
The RIPE-690 BCOP document had originally tried to address this problem
by recommending operators to lease stable IPv6 prefixes to CPE routers.
However, for a variety of reasons ISP may not be able (or may not want)
to lease stable prefixes, and may instead lease dynamic prefixes.
Most of the voices on the 6man wg mailing-list fell into one of the
following camps:
* "ISPs should be leasing stable prefixes -- if they don't, they are
asking for trouble!"
* "CPE routers should record leased prefixes on stable storage, such
that they can 'deprecate' such prefixes upon restart -- if they
don't, they are asking for trouble!"
* "No matter whose fault is this (if there is any single party to blame
in the first place), we should improve the robustness of IPv6
deployments"
Our Internet-Draft tries to improve the current state of affairs via the
following improvements:
* Allow hosts to gracefully recover from stale network configuration
information -- i.e., detect and discard stale network configuration
information
* Have SLAAC routers employ more appropriate timers, such that
information is phased-out in a timelier manner -- unless it is
actively refreshed by Router Advertisement messages
* Specify the interaction between DHCPv6-PD and SLAAC -- which was
rather under-specified
* Require CPE routers to store leased prefixes on stable storage, and
deprecate stale prefixes (if necessary) upon restart
We are looking forward to more input on the document (or any comments on
the issue being discussed), particularly from operators.
So feel free to send your comments on/off list as you prefer
Thanks!
Cheers,
--
Fernando Gont
SI6 Networks
e-mail: fgont(a)si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
Folks,
The Internet Society has posted the "IPv6 Security Frequently Asked
Questions (FAQ)" I authored.
The document is available (HTML, and also easy-to-print PDF) at:
https://www.internetsociety.org/deploy360/ipv6/security/faq/
If you think there are other questions that should be added, or have
comments on the answers, please do let me know -- the document can
eventually be revised.
Thanks!
Cheers,
--
Fernando Gont
SI6 Networks
e-mail: fgont(a)si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
Dear colleagues,
In this article, Andy Mindnich describes how IPv6 was introduced inside
IBM’s own network over the past few years. As enterprises in general
seem to lag behind in adopting IPv6 as compared to ISPs or carriers,
this article is aimed at helping those who still need to build a case
within their own company.
https://labs.ripe.net/Members/andy_mindnich/deploying-ipv6-at-ibm
Kind regards,
Mirjam Kühne
RIPE NCC
Folks,
We have posted a new I-D discussing a problem that can arise in typical
deployment scenarios where the CPE obtains a prefix via DHCPv6-PD and
advertises a prefix on the LAN side. We also propose a solution to the
aforementioned problem.
Our draft is available at:
https://tools.ietf.org/html/draft-gont-6man-slaac-renum
The Abstract is:
A very common IPv6 deployment scenario is that in which a CPE employs
DHCPv6 Prefix Delegation to obtain an IPv6 prefix, and at least one
prefix from within the leased prefix is advertised on a local network
via SLAAC. In scenarios where e.g. the CPE crashes and reboots,
nodes on the local network continue using outdated prefixes which
result in connectivity problems. This document analyzes this problem
scenario, and proposes workarounds.
Any comments will be welcome.
Thanks!
Cheers,
--
Fernando Gont
SI6 Networks
e-mail: fgont(a)si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
Hello All,
The RIPE 78 meeting will take place will take place in Reykjavik Iceland from 20-24 May 2019.
https://ripe78.ripe.net/
The IPv6 WG session will most likely be on Thursday after lunch. (still subject to change).
Would you like to present at our WG session, and have a subject that would be of interest on IPv6?
We, the IPv6 WG co-chairs, would like to invite you to submit your presentation proposals, including a brief description of the content and the time you would need.
Please send them directly to us: ipv6-wg-chairs at ripe.net<https://lists.ripe.net/mailman/listinfo/ipv6-wg> .
Once we start to make the final agenda, we will let you know if you are selected or not.
Please be aware of the following:
Due to potential technical issues, presenters/panelists should be physically present at the RIPE Meeting.
RIPE Meeting attendees are quite sensitive to keeping presentations non-commercial, and product marketing talks are strongly discouraged.
All sessions will be recorded and broadcasted, and will be publicly available afterwards, so make sure you own the copyrights of all content.
See you in Reykjavik,
Jen, Benedikt, Ray
