IPv6 experiments at future RIPE Meetings
Reading the minutes of the IPv6 WG at RIPE 59 I read:
David asked the audience if the IPv6 Hour should be rerun at future meetings.. There is consensus that it should be.
Rob Blokzijl has asked that we treat the RIPE Meeting network as a production network. This effectively means that we won't be turning off the dual-stack network for another "IPv6 Hour". What we can do is to build the IPv6 only networks as we did in Berlin and make these available to anyone who wants to use them, but without the complications caused by the IPv6 Hour. One question that remains is whether, with rfc2766 now "historic", providing NAT-PT on the IPv6-only networks is worthwhile for RIPE 60 and future meetings. Would it be enough just to provide the IPv6 networks but without any translation to be able to reach the IPv4 legacy Internet? Any feedback would be appreciated. Regards, James -- James Aldridge, Senior Systems & Network Engineer, RIPE NCC RIPE Meeting technical team
James Aldridge wrote:
One question that remains is whether, with rfc2766 now "historic", providing NAT-PT on the IPv6-only networks is worthwhile for RIPE 60 and future meetings. Would it be enough just to provide the IPv6 networks but without any translation to be able to reach the IPv4 legacy Internet?
Is there any NAT64/DNS64 mechanism out there in running-code yet? I hear Cisco will deploy this in some experimental IOS later this year. I suspect this also to be crap like NAT-PT, but we never know... /jan
On 02/02/2010 14:18, James Aldridge wrote:
David asked the audience if the IPv6 Hour should be rerun at future meetings.. There is consensus that it should be. Rob Blokzijl has asked that we treat the RIPE Meeting network as a
Reading the minutes of the IPv6 WG at RIPE 59 I read: production network. This effectively means that we won't be turning off the dual-stack network for another "IPv6 Hour". [...] Any feedback would be appreciated.
Thank you. A good position, James. There is a difference between advocacy and forcing v6 down peoples' throats. Proving the dual-stack model works is important enough. Maybe we can force dual stack down people's throats by forcing a registration portal that was only available via v6, once complete you had access to the production dual stack network ? ;-) Andy
James Aldridge a écrit :
Reading the minutes of the IPv6 WG at RIPE 59 I read:
David asked the audience if the IPv6 Hour should be rerun at future meetings.. There is consensus that it should be.
Rob Blokzijl has asked that we treat the RIPE Meeting network as a production network. This effectively means that we won't be turning off the dual-stack network for another "IPv6 Hour".
What we can do is to build the IPv6 only networks as we did in Berlin and make these available to anyone who wants to use them, but without the complications caused by the IPv6 Hour.
One question that remains is whether, with rfc2766 now "historic", providing NAT-PT on the IPv6-only networks is worthwhile for RIPE 60 and future meetings. Would it be enough just to provide the IPv6 networks but without any translation to be able to reach the IPv4 legacy Internet?
we have an implementation of nat64 that we will be running in a well-known internet engineering conference in the next weeks for that reason. We could bring it to RIPE if you like. Marc.
Any feedback would be appreciated.
Regards, James
James, On 2010-02-02 15:18, James Aldridge wrote:
Reading the minutes of the IPv6 WG at RIPE 59 I read:
David asked the audience if the IPv6 Hour should be rerun at future meetings.. There is consensus that it should be.
Rob Blokzijl has asked that we treat the RIPE Meeting network as a production network. This effectively means that we won't be turning off the dual-stack network for another "IPv6 Hour".
Sure, makes sense.
What we can do is to build the IPv6 only networks as we did in Berlin and make these available to anyone who wants to use them, but without the complications caused by the IPv6 Hour.
One question that remains is whether, with rfc2766 now "historic", providing NAT-PT on the IPv6-only networks is worthwhile for RIPE 60 and future meetings. Would it be enough just to provide the IPv6 networks but without any translation to be able to reach the IPv4 legacy Internet?
Any feedback would be appreciated.
For the IPV6-only with translation, we should consider one of the transition tools now available. ISC (my company, although I have had no involvement with this software) just released AFTR: https://www.isc.org/software/aftr It's open source, gratis, libre, and so on. I do think RIPE meetings should switch to RFC 1918 addresses for both IPv4/IPv6 and IPv4-only networks ASAP. These are heavily used, even in production networks. Probably too late for the next RIPE meeting, but shouldn't be a problem for subsequent ones. -- Shane
Hi, On Tue, Feb 02, 2010 at 03:53:11PM +0100, Shane Kerr wrote:
On 2010-02-02 15:18, James Aldridge wrote:
Rob Blokzijl has asked that we treat the RIPE Meeting network as a production network. [..]
I do think RIPE meetings should switch to RFC 1918 addresses for both IPv4/IPv6 and IPv4-only networks ASAP.
"Production network" is not compatible with "RFC 1918" addresses. There is no need to make IPv4 available-but-less-useful - if we don't want IPv4, let's turn it off, but don't pretend. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 144438 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
Gert, On 2010-02-02 16:21, Gert Doering wrote:
Hi,
On Tue, Feb 02, 2010 at 03:53:11PM +0100, Shane Kerr wrote:
On 2010-02-02 15:18, James Aldridge wrote:
Rob Blokzijl has asked that we treat the RIPE Meeting network as a production network. [..]
I do think RIPE meetings should switch to RFC 1918 addresses for both IPv4/IPv6 and IPv4-only networks ASAP.
"Production network" is not compatible with "RFC 1918" addresses.
There is no need to make IPv4 available-but-less-useful - if we don't want IPv4, let's turn it off, but don't pretend.
I kind of understand where you're coming from. You hate NAT. It is a common position of anyone who has had to work with it. :) But the idea that no production networks can use RFC 1918 is a bit disturbing, because in 2 years or so there won't be any IPv4 addresses left, and people will be forced to use RFC 1918 addresses. Does that mean there won't be any IPv4 production networks in 2013? My intention is not to make IPv4 available-but-less-useful, but rather to begin using the same setup that all event organizers will have to use in the future. It's not that bad, really - I use RFC 1918 networks all the time. I'm using one now (well, except for the 0.01% of the Internet with working IPv6). The Internet seems to work pretty good with RFC 1918 + IPv6. -- Shane
Hi, On Tue, Feb 02, 2010 at 04:58:36PM +0100, Shane Kerr wrote:
But the idea that no production networks can use RFC 1918 is a bit disturbing, because in 2 years or so there won't be any IPv4 addresses left, and people will be forced to use RFC 1918 addresses. Does that mean there won't be any IPv4 production networks in 2013?
IPv4 is clearly last century's IP protocol... you know that. In 2013, existing IPv4 production networks will continue to work, of course - and new IPv4 deployments will feel massive amounts of pains. And no, I don't consider "new IPv4 networks without available address space" to be "production networks".
My intention is not to make IPv4 available-but-less-useful, but rather to begin using the same setup that all event organizers will have to use in the future.
Why should we run with the masses? What will be next, "turn off IPv6 because all the other event organizers don't have v6 either"? *shake head*
It's not that bad, really - I use RFC 1918 networks all the time. I'm using one now (well, except for the 0.01% of the Internet with working IPv6). The Internet seems to work pretty good with RFC 1918 + IPv6.
This is not "Internet". This is "I go out and pull stuff from servers that are run in real IP Space". Internet means "having machines that are reachable without major contortions on the devices in between" (= NAT forwardings). (despite the religious aspects, there's a purely practical aspect - if you force RIPE attendees into RFC1918 space, you're going to kill VPN connects for those poor souls that have a home network in the *same* RFC1918 address range. Which will break almost all VPN clients out there.) Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 144438 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
Hi, i must say i second Gert and Jan their position against the use of NAT, for pretty much the same stated reasons. Apart from all the tecnical details of what will work/not work/possible not work, and any personal position about the good and the bad of NATting, please note that enabling NAT on the meeting network would be against the currently running laws of at least one of the country hosting one of the next RIPE meetings: Italy (for any of you interested on it it's art. 6, comma 5, d.lgs 109/2008) Which, roughly translated, states that starting from march 21 2009 "any access provider, providing public connectivity (which means connecting people to the Internet), must ensure effective avalability and unicity of ip addresses assigned to the end user. Which means that if you want to comply to the law you MUST assign a public ip address to any user you connect (and by the way if you give internet access on public locations you should also be able to track down the identity of each single user that has connected, including a copy of an ID document or some other allowed certain identification methods). No need to comment on that law, no one here in Italy really likes it at all, but that's it, up to now, and at least until next december 31st we do have to live with it. I think the chances of network abuses during a RIPE meeting are quite low, but i really would avoid seeing a RIPE meeting pushing, even if indirectly and unwanted, some unlawful behaviour. Thanks, Ricky
On 2 feb 2010, at 18:34, Riccardo Losselli wrote:
Hi, i must say i second Gert and Jan their position against the use of NAT, for pretty much the same stated reasons.
Count me in, we should indeed consider the network as production and not do any experiments with it. I also wonder what we tend to prove to try and prove ourselves with that, the fact that NAT is evil and should not be used or are we going to make sure it works and show the world there is really nothing to worry about and there is no need to invest in IPv6 at all ? In either case, dping such at the ripe meeting is more or less a matter of preaching to the choir, most regular visitors should be already aware and if it's there first time we can probably convince them about the urgency without breaking our own connectivity. But maybe...there is a large group who is not aware, but those are usually not the folks visiting the RIPE meeting, but usually reside somewhere on the executive floor or stock market trading rooms. Why not instead of experimenting on our own come up with a bunch of usefull instructions to do-it-yourself, so people all over can use this is a tool to convince $boss that NAT is not a solution. Stuff I think is a 10 step instruction on how to limit the number of open tcp sessions on a box to some low number so they can experience for themselves those famous google maps pictures are for real and not something put together by the IPCC. MarcoH
On 02.02.10 19:07, Gert Doering wrote:
(despite the religious aspects, there's a purely practical aspect - if you force RIPE attendees into RFC1918 space, you're going to kill VPN connects for those poor souls that have a home network in the *same* RFC1918 address range. Which will break almost all VPN clients out there.)
Gert, seems you dramatize the situation - there are more issues - to be honest. The situations can be more complex. But I don't see any specific differences with access to corporate intranets and still had no problem in such mixed enviroments using appropriative tools for years. Dima
Gert Doering -- NetMaster
Hi, On Tue, Feb 02, 2010 at 09:43:48PM +0300, Dmitry Burkov wrote:
On 02.02.10 19:07, Gert Doering wrote:
(despite the religious aspects, there's a purely practical aspect - if you force RIPE attendees into RFC1918 space, you're going to kill VPN connects for those poor souls that have a home network in the *same* RFC1918 address range. Which will break almost all VPN clients out there.)
Gert, seems you dramatize the situation - there are more issues - to be honest. The situations can be more complex. But I don't see any specific differences with access to corporate intranets and
If we use 192.168.1.0/24 for the RIPE meeting, and your corporate network at home uses 192.168.1.0/24 as well, most VPN clients will NOT be able to build a working connection. Try it. Given the number of attendees, the chances for address collisions with at least one participant's home network can be assumed to be near 100%. We've been fighting with this issue for years now - people stay at hotels and want to connect to their home network, and that network happens to use the same RFC 1918 address block as the hotel. (Add to that the problems many N:1 NAT/PAT implementations have with multiple parallel IPSEC sessions). NAT and RFC1918 are fine tools for corporate environments that don't *want* any communication besides clearly defined exceptions. But that's not "useful Internet". Don't go there, just "because everbody else does". (*Especially* not for that stupid reason. We're not sheep.) Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 144438 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
Gert, On Tue, Feb 02, 2010 at 09:36:10PM +0100, Gert Doering wrote:
Given the number of attendees, the chances for address collisions with at least one participant's home network can be assumed to be near 100%.
So use NAT'ed public IPv4 addresses ? (yuk!) But seriously, we will be living in this ugly world not long from now, whether we like it or not. Why not try it out before it will be forced on us? At least this time you can relatively easy bypass the NAT by using IPv6 and there is still time to find out about the worst problems like you mention above and make it work. David Kessens ---
On Feb 2, 2010, at 3:43 PM, David Kessens wrote: […]
But seriously, we will be living in this ugly world not long from now, whether we like it or not. Why not try it out before it will be forced on us?
I agree with this statement. I think there is real value in experiencing the kinds of problems we are likely to see when the IPv4 address space has been fully allocated and further network growth cannot use unique IPv4 addresses. Having an optional CGN-style network to see what works and what needs to be improved would be genuinely useful. Regards, Leo Vegoda
Hi, On Tue, Feb 02, 2010 at 04:20:55PM -0800, Leo Vegoda wrote:
But seriously, we will be living in this ugly world not long from now, whether we like it or not. Why not try it out before it will be forced on us?
I agree with this statement. I think there is real value in experiencing the kinds of problems we are likely to see when the IPv4 address space has been fully allocated and further network growth cannot use unique IPv4 addresses. Having an optional CGN-style network to see what works and what needs to be improved would be genuinely useful.
At the beginning of this thread, it was stated that the RIPE meeting network is not to be treated as an experiment or testbed. If people think there is an interest in having a NAT-broken network around, then please make it available on a dedicated SSID, but don't experiment with the meeting network. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 144438 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
On Wed, 2010-02-03 at 10:01 +0100, Gert Doering wrote:
If people think there is an interest in having a NAT-broken network around, then please make it available on a dedicated SSID, but don't experiment with the meeting network.
Long version: After having read this thread, this one paragraph by Geert makes a lot of sense. Points made in this thread were, in the order my client presented them to me: 1) Do not experiment with the RIPE meeting network 2) Do not push single-stack IPv6 down people's throat 3) Do push bleeding IPv4 down people's throat 4) Testing out what the rest of the world shortly will experience is useful Given 1), it makes a lot of sense to put 2) + 3) on a separate SSID. Give it a well-descriptive name and that's it... Problem solved! Attendees can do testing on their *own* terms, which is bound to make them happier. Short version: I second this statement. :) Regards, -- Martin Millnert <millnert@csbnet.se>
On Wednesday 03 February 2010 05:58:01 pm Martin Millnert wrote:
Given 1), it makes a lot of sense to put 2) + 3) on a separate SSID. Give it a well-descriptive name and that's it... Problem solved! Attendees can do testing on their *own* terms, which is bound to make them happier.
This is what we do, shall be doing and have done at a regional meeting in Asia-Pac. Cheers, Mark.
Martin, On 2010-02-03 10:58, Martin Millnert wrote:
On Wed, 2010-02-03 at 10:01 +0100, Gert Doering wrote:
If people think there is an interest in having a NAT-broken network around, then please make it available on a dedicated SSID, but don't experiment with the meeting network.
Short version:
I second this statement.
This makes sense. Although of course I would like this to be something like: RIPE 61: ESSID RIPE is globally-unique IPv4+IPv6, ESSID RIPE-NAT is NAT IPv4 plus globally-unique IPv6 RIPE 63: ESSID RIPE is NAT IPv4 plus globally-unique IPv6 ESSID RIPE-NO-NAT is globally unique IPv4+IPv6 In the future we could further mimic the "real world" by charging money for the use of the RIPE-NO-NAT network. For a sufficently massive fee we could probably even keep addresses persistent between meetings. ;) -- Shane
On 3 Feb 2010, at 10:01, Gert Doering wrote:
At the beginning of this thread, it was stated that the RIPE meeting network is not to be treated as an experiment or testbed.
If people think there is an interest in having a NAT-broken network around, then please make it available on a dedicated SSID, but don't experiment with the meeting network.
yep, I agree. The last thing I need at a RIPE meeting is to have to spend additional time figuring out how the to get the net working. When attending a RIPE meeting I still need to carry on with normal work, it is not a vacation. Additionally, experiments are better done in controlled situations where one actually has the means to address the findings. BTW, IPv6 ought to continue to be considered as a production service on the RIPE network, just in case. Joao
On Feb 3, 2010, at 1:01 AM, Gert Doering wrote:
On Tue, Feb 02, 2010 at 04:20:55PM -0800, Leo Vegoda wrote:
But seriously, we will be living in this ugly world not long from now, whether we like it or not. Why not try it out before it will be forced on us?
I agree with this statement. I think there is real value in experiencing the kinds of problems we are likely to see when the IPv4 address space has been fully allocated and further network growth cannot use unique IPv4 addresses. Having an optional CGN-style network to see what works and what needs to be improved would be genuinely useful.
At the beginning of this thread, it was stated that the RIPE meeting network is not to be treated as an experiment or testbed.
Indeed. That's why I included the word "optional". Leo
Hi, On Tue, Feb 02, 2010 at 03:43:48PM -0800, David Kessens wrote:
On Tue, Feb 02, 2010 at 09:36:10PM +0100, Gert Doering wrote:
Given the number of attendees, the chances for address collisions with at least one participant's home network can be assumed to be near 100%.
So use NAT'ed public IPv4 addresses ? (yuk!)
But seriously, we will be living in this ugly world not long from now, whether we like it or not. Why not try it out before it will be forced on us?
I'm sure that whoever wants to break their IPv4 connectivity can nicely do so at home. "Just because IPv4 is broken for people" is no compelling argument to reduce the usefulness of the meeting network for those that have no IPv6 yet.
At least this time you can relatively easy bypass the NAT by using IPv6 and there is still time to find out about the worst problems like you mention above and make it work.
*I* could live quite well with an IPv6-only network. But that's not the point. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 144438 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
Shane Kerr wrote:
But the idea that no production networks can use RFC 1918 is a bit disturbing, because in 2 years or so there won't be any IPv4 addresses left, and people will be forced to use RFC 1918 addresses. Does that mean there won't be any IPv4 production networks in 2013?
Shane, Please, don't push the CGN(or LSN) idea any further. NAT-ing the whole ISP networks would permanently kill end2end paradigm. I don't want to see my whole city or even country to operate in RFC1918 address space behind one big NAT in near future. Sorry, I agree with Gert. :) /jan
Hi James & all, I missed the "Berlin experiment" and i honestly feel those experiments are only useful to allow "IPv6 advocates" to check if they can really live/function without the "safety net" that IPv4 really is. :-) I already know i can have 100% functionality with IPv6-only, because there is some stuff on my domain that i have absolutely no control. IMHO, for the meeting "neutral attendee" this kind of experiment may become a pain, and it may, to some extent, create/increase resistance to IPv6 usage/deployment. So, if the NCC is interested in allowing people to test how ready they really are to survive without IPv4 i would advice on installing one wifi access point a bit away from where most people concentrate, and clearly tag that area as "No IPv4 available here". You might even want to "stamp" the floor with colorful arrows driving people for the edge "Test-how-will-you-survive-without-v4" zone. :-)) Best Regards, Carlos On Tue, 2 Feb 2010, James Aldridge wrote:
Reading the minutes of the IPv6 WG at RIPE 59 I read:
David asked the audience if the IPv6 Hour should be rerun at future meetings.. There is consensus that it should be.
Rob Blokzijl has asked that we treat the RIPE Meeting network as a production network. This effectively means that we won't be turning off the dual-stack network for another "IPv6 Hour".
What we can do is to build the IPv6 only networks as we did in Berlin and make these available to anyone who wants to use them, but without the complications caused by the IPv6 Hour.
One question that remains is whether, with rfc2766 now "historic", providing NAT-PT on the IPv6-only networks is worthwhile for RIPE 60 and future meetings. Would it be enough just to provide the IPv6 networks but without any translation to be able to reach the IPv4 legacy Internet?
Any feedback would be appreciated.
Regards, James
-- James Aldridge, Senior Systems & Network Engineer, RIPE NCC RIPE Meeting technical team
Hi, I see plain IPv6 without any kind of IPv4 support including protocol translation as very nice idea there. People could see how much (or how few if I would like to be accurate and/or sarcastic) of public and their own private services like their SSH, POP3, SMTP or IM accounts could be reached by IPv6. It could be also a motivation for a lot of people to make more services v6 available *before* the meeting. I see a lot of v6 enabled networks but only a small amount of v6 enabled services. BR, Zbynek Dne 2.2.10 15:56, Carlos Friacas napsal(a):
Hi James & all,
I missed the "Berlin experiment" and i honestly feel those experiments are only useful to allow "IPv6 advocates" to check if they can really live/function without the "safety net" that IPv4 really is. :-)
I already know i can have 100% functionality with IPv6-only, because there is some stuff on my domain that i have absolutely no control.
IMHO, for the meeting "neutral attendee" this kind of experiment may become a pain, and it may, to some extent, create/increase resistance to IPv6 usage/deployment.
So, if the NCC is interested in allowing people to test how ready they really are to survive without IPv4 i would advice on installing one wifi access point a bit away from where most people concentrate, and clearly tag that area as "No IPv4 available here". You might even want to "stamp" the floor with colorful arrows driving people for the edge "Test-how-will-you-survive-without-v4" zone. :-))
Best Regards, Carlos
Hi all,
I see plain IPv6 without any kind of IPv4 support including protocol translation as very nice idea there. People could see how much (or how few if I would like to be accurate and/or sarcastic) of public and their own private services like their SSH, POP3, SMTP or IM accounts could be reached by IPv6. It could be also a motivation for a lot of people to make more services v6 available *before* the meeting. I see a lot of v6 enabled networks but only a small amount of v6 enabled services.
This is a good point, but I find myself with a competing requirement. One of the parts of my company's IPv4 depletion strategy is to make a service where a new customer can connect with IPv6 only, but still access the whole internet in some way, including the IPv4 part. I think that this is one of the most important and least developed parts of the technology, and we have few enough opportunities to see it tested. All the best, Dave -- Dave Wilson, Senior Network Engineer HEAnet Limited, Ireland's Education and Research Network 1st Floor, 5 George's Dock, IFSC, Dublin 1 Registered in Ireland, no 275301 tel: +353-1-660 9040 fax: +353-1-660 3666 web: http://www.heanet.ie/ H323 GDS:0035301101738 PGP: 1024D/C757ADA9
participants (17)
-
Andy Davidson -
Carlos Friacas -
Dave Wilson -
David Kessens -
Dmitry Burkov -
Gert Doering -
James Aldridge -
Jan Zorz ＠ go6.si -
João Damas -
Leo Vegoda -
Marc Blanchet -
Marco Hogewoning -
Mark Tinka -
Martin Millnert -
Riccardo Losselli -
Shane Kerr -
Zbynek Pospichal