[ipv6-wg] Presentation Proposal
Hi guys, as Chris asked me (some time ago---some things just won't change...) here's a first draft of a proposal for a presentation in Prague: "The road ahead: Where are we with IPv6, and what needs to be done next?" We've been aiming at a 15 minute slot, but as always I've got more than enough to talk about if you have more time to fill. (Ray probably remembers how I prepared a presentation overnight because Fernando hadn't even registered to the meeting in Rotterdam(?) until hours before his slot...) Anyway, what might actually stir up some discussion is that we may get into serious problems with the size of the IPv6 routing table in the default free zone. Cheers, Benedikt -- Business Grade IPv6 Consulting, Training, Projects Stepladder IT Training+Consulting GmbH Benedikt Stockebrand Fichardstr. 38, 60322 Frankfurt/MainDipl.-Inform./Geschäftsführer HRB 94202, Registergericht Frankfurt/M cont...@stepladder-it.com http://www.stepladder-it.com/ +49 (0) 69 - 247 512 362 BIVBlog---Benedikt's IT Video Blog: http://www.stepladder-it.com/bivblog/ Bitte kein Spam, keine unaufgeforderten Werbeanrufe, keine telefonischen Umfragen. Anrufe werden ggf. zu rechtlichen Zwecken aufgezeichnet. No spam, no unsolicited sales calls, no telephone surveys, please. Calls may be recorded for legal purposes. - To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/ipv6-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
[ipv6-wg] Not standing as working group chair for another term
Hi folks, as I've already said during the working group session in Rotterdam my term as WG chair ends at the next RIPE meeting. Since I find it increasingly difficult to make the WG chair role agree with my daily work profile (too much firefighting, too little of a routine daily schedule), Jen and Ray had to cover for me more often than I am happy with---thanks, and apology, to both of them. As a consequence however it doesn't make any sense if I stood for another term. We'll start the process of finding a successor for me before RIPE 87. If you are interested in taking over the role, and are willing to keep a pretty much daily eye on the mailing list and such, you may already want to think about volunteering for the job. And one more thing: That doesn't mean that I have lost interest in the WG, or in IPv6 as such---in fact, in my opinion we still have some serious work to do eliminating the hidden dependencies on Vintage IP before they bite us in the backside. More about that at RIPE 87 in Rome... Cheers, Benedikt -- Benedikt Stockebrand, Stepladder IT Training+Consulting Dipl.-Inform. http://www.stepladder-it.com/ Business Grade IPv6 --- Consulting, Training, Projects BIVBlog---Benedikt's IT Video Blog: http://www.stepladder-it.com/bivblog/ -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/ipv6-wg
Re: [ipv6-wg] Invitation to supply feedback on ITU draft Recommendation on IPv6 address planning for IoT
s otherwise been removed from the network into the IPv6-only period. 4. The model precludes the application of several of the most basic --- security measures considered best practice by todays standards -- In enterprise and other data center environments, microsegmentation and hierarchical security zones as well as a number of other, more specific designs, are used to reach a sufficient level of security. All of these measures however require a network design that can't be implemented within the constraints of the proposed model except through an excessive bloat of the routing tables, firewall configurations and application based access control lists involved. Depending on the security requirements of the given network environment, this is unacceptable at best and violating various legal requirements at worst. 5. The model shortens the expected usable life time of IPv6 by at least --- 25%, or 42+ years at the current Internet growth IP addresses by their very design are supposed to hold all the information needed to route IP packets from their source to their destination. As such IP addresses must be assigned in a way that matches the chosen network topology, and nothing else. The proposed model however effectively re-purposes two octets of data for purposes unrelated to routing. Applying the HD ratio concept (as used for IPv6 subnets in general), or basic information theory (Shannon 1948/1949), this can be worked into more palatable numbers: The proposed model - reduces the number of usable subnet prefixes to 1/65536 = 0.00153% of the address space, - at a continued exponential growth of the Internet reduces the expected usable life time of IPv6 by (64-48)/64 or 25% and - at a continued exponential growth of the Internet by the commonly measured/estimated factor of 1.3/year, reduces the effective life time by log_1.3(2**16)=42.27 years. This doesn't even take into account the impact it has on the size of routing tables, access control lists and such, which may or may not reduce the usable life time of IPv6 at the Internet level even further. Only when the network topology correlates, or is made to correlate, the encoding of the categorization data in the addresses could this effect be slightly reduced. Trying to make use of this fact will however make network design decidedly more complex while at the same time only generating a marginal effect. Conclusion == Following from the results of this analysis---which is by no means meant to be complete---the proposed reference model is ill-conceived and critically endangers the future of the Internet. ---8<--- -- Benedikt Stockebrand, Stepladder IT Training+Consulting Dipl.-Inform. http://www.stepladder-it.com/ Business Grade IPv6 --- Consulting, Training, Projects BIVBlog---Benedikt's IT Video Blog: http://www.stepladder-it.com/bivblog/
Re: [ipv6-wg] Chair election
Hi everyone, Jetten Raymond writes: > I have not seen any comments on this? I'm pretty sure this means that nobody on the list is seriously unhappy with Jen as a Chair---big surprise:-) > As a co-chair I want to say I'm very happy with all the work Jen is > doing, and above all it’s a pleasure to work with her. Absolutely the same here; I wouldn't have stood for re-election myself last time if I didn't like to work with my fellow chairs. > Don’t know if my vote counts, but Sure, we're also somehow involved in the working group... > +1 Make that a +2. See you all in Marseille, Benedikt -- Benedikt Stockebrand, Stepladder IT Training+Consulting Dipl.-Inform. http://www.stepladder-it.com/ Business Grade IPv6 --- Consulting, Training, Projects BIVBlog---Benedikt's IT Video Blog: http://www.stepladder-it.com/bivblog/
[ipv6-wg] Same procedure as every year: Chair (Re-)election
Hi IPv6 working group, looks like it's time we did a bit of paperwork... According to the "IPv6 WG Chair Selection Process"[1] it is time for one of us chairs to step down and possibly stand again for re-election. Jen and I fought it out (and what you'd expect, I lost:-) and it was decided that I'll step down---to stand for re-election---effective the next WG meeting in Dubai. With the way things have worked out, I'd be more than happy to serve another term as a WG chair. Cheers, Benedikt [1] https://www.ripe.net/participate/ripe/wg/ipv6/ipv6-wg-chair-selection-process -- Benedikt Stockebrand, Stepladder IT Training+Consulting Dipl.-Inform. http://www.stepladder-it.com/ Business Grade IPv6 --- Consulting, Training, Projects BIVBlog---Benedikt's IT Video Blog: http://www.stepladder-it.com/bivblog/
Re: [ipv6-wg] [ipv6-wg-chair] IMPORTANT: RIPE75 is SPECIAL (call for presentations)
Hi folks, first off: I am not a lawyer; this is just what I as a layman found out about this. Daniel Roesen writes: > On Tue, Jul 04, 2017 at 07:55:01AM +1000, Jen Linkova wrote: >> 2) all speakers (including remote presenters) need to provide a colour >> copy of their passport and a short bio (min 2000 chars). > > This would be illegal for Germans to do. Except for some very specific > exceptions and under several severe restrictions involving redacting out > any data on the ID not strictly required for identification, Germans are > not allowed to make photocopies of their passports or personal IDs, or > let others make those. Are you sure this applies to passports? I know it's the rule about national ID cards (Personalausweis), but the main reason for that is that it contains things like your current home address and whatnot that you don't actually find in a passport. And no matter what I think about the competence levels of your bureaucracy in general, I'd be kind of surprised if they didn't realize that around the world passports *do* get copied. The important issue however with German passports is Par. 18(3) of the PassG. According to this the RIPE NCC might not be allowed to pass the passport copy on to the DTCM, but I'm not sure if this applies because it is passed on to a (foreign) public service. > Was this requirement known to the organizers before deciding on venue > country? If I understand correctly it is one of these ancient rules that haven't been actually applied for an eternity until recently---way after the decision to go to Dubay---someone decided to actually apply it. Until then to my knowledge (ask Hans Petter or whoever) it wasn't even known to the NCC that this sort of requirement existed. And from the discussions on the working group chair list alone I guess the hassle this causes to the NCC, the WG chairs and whoever els is substantial enough to cause quite some headaches. Cheers, Benedikt -- Business Grade IPv6 Consulting, Training, Projects Stepladder IT Training+Consulting GmbH Benedikt Stockebrand Fichardstr. 38, 60322 Frankfurt/MainDipl.-Inform./Geschäftsführer HRB 94202, Registergericht Frankfurt/M cont...@stepladder-it.com http://www.stepladder-it.com/ +49 (0) 69 - 247 512 362 http://www.benedikt-stockebrand.de/ +49 (0) 177 - 41 73 985 BIVBlog---Benedikt's IT Video Blog: http://www.stepladder-it.com/bivblog/ Bitte kein Spam, keine unaufgeforderten Werbeanrufe, keine telefonischen Umfragen. Anrufe werden ggf. zu rechtlichen Zwecken aufgezeichnet. No spam, no unsolicited sales calls, no telephone surveys, please. Calls may be recorded for legal purposes.
Re: [ipv6-wg] Chair selection: call for candidates
Hi Anna, Jen and list, Jen Linkova writes: > Let me thank you for all your work as a WG co-chair! same from me! I guess most people here have noticed that you were the one largely taking care of the chair (s)election policy, but what might be less obvious is that you really helped Jen and me to find our way around in our then new role as WG chairs. Cheers, and thanks again, Benedikt -- Benedikt Stockebrand, Stepladder IT Training+Consulting Dipl.-Inform. http://www.stepladder-it.com/ Business Grade IPv6 --- Consulting, Training, Projects BIVBlog---Benedikt's IT Video Blog: http://www.stepladder-it.com/bivblog/
Re: [ipv6-wg] IPv6 cloud!
Hi Colin and list, Colin Petrie writes: > [Problems with VPNs over DS-Lite] > > (Of course I sent the ISP tcpdumps and a full analysis pointing out to > them that the firmware in the CPE they provided me was broken. They > decided to fix it by sending me a different model of CPE. I doubt they > ever escalated it to actually fix the underlying problem in the original > CPE. But if you happen to have a Technicolor TC7200, be wary of its > DS-Lite implementation!) that's what I've mentioned(?) before: These issues occur at a reasonably large scale, so they need to be handled by first, or at most second, level support. But show me any first level supporter able to diagnose that, or even understand what a tcpdump is or what it means. They simply don't have a chance. Aimlessly beating at the problem until the customer shuts up (no matter if his problem is solved or he just gave up) is pretty much all they can do. But that doesn't mean that you want to rely on that sort of setup. Cheers, Benedikt -- Benedikt Stockebrand, Stepladder IT Training+Consulting Dipl.-Inform. http://www.stepladder-it.com/ Business Grade IPv6 --- Consulting, Training, Projects BIVBlog---Benedikt's IT Video Blog: http://www.stepladder-it.com/bivblog/
Re: [ipv6-wg] IPv6 cloud!
Hi Andrew and list, Andrew 👽 Yourtchenko writes: > An idea: Next time you meet the folks encountering the problems, > suggest them to google for "go6 nat64" and configure their resolver to > one of Jan's NAT64 test DNS64s, and then turn off IPv4 on their host > completely. to my knowledge that won't help in any way with their STUN/SIP problems. It will also add to latency. And if Jan's setup gets overloaded, then the overall result won't help them any. But I'll point them that way next time I get into such a situation. Cheers, Benedikt -- Benedikt Stockebrand, Stepladder IT Training+Consulting Dipl.-Inform. http://www.stepladder-it.com/ Business Grade IPv6 --- Consulting, Training, Projects BIVBlog---Benedikt's IT Video Blog: http://www.stepladder-it.com/bivblog/
Re: [ipv6-wg] IPv6 cloud!
Hi Ole and list, "Ole Troan (otroan)" writes: >> Considering the increasing reports of people having problems with >> DS-Lite > > Any more details on that? > New problems not mentioned in RFC6269? sorry I haven't got the time right now to review RFC6269 for what's exactly mentioned there and what isn't, but: When I do IPv6 trainings these days it's about one in eight who is struggling with their land line access, which is based on DS-Lite and which reasonably well matches the estimated percentage of DS-Lite on land lines. The problems are however of a somewhat different nature than what RFC6269 addresses; they are roughly these: - Various services don't work. Like STUN, and due to that, SIP. And apparently various VPN solutions, too, but I never got access to any details with this. The real culprit here seems to be restricted cone NAT in the AFTR, plus apparently IPsec not working through DS-Lite. - There have been multiple reports that during peak hours there are significant connection drops. The impact varies from user to user as well as from ISP to ISP, apparently. Or as one user put it: "I solved the problem. I just don't even try to access IPv4-only web pages on saturday afternoons any longer." I don't have access to the AFTRs involved, so I can't reliably tell what's happening there, but from the descriptions I got it looks like some of them are actually running out of memory/CAM during peak hours and start to drop the connections. This is economically plausible, too, since the ISPs won't spend significant money on AFTR hardware until problems have already shown up. - First level support is frequently completely helpless when confronted with DS-Lite, or even IPv6 in general. The most annoying aspect here is that frequently it comes across that "it's a problem with IPv6" and "if you keep complaining they'll switch it off again for you" (i.e. they go back to IPv4-only connectivity without restricted cone NAT). All the information I have here is largely based on anecdotal reports, but enough of them for me to consider these problems anything but isolated cases. Cheers, Benedikt -- Benedikt Stockebrand, Stepladder IT Training+Consulting Dipl.-Inform. http://www.stepladder-it.com/ Business Grade IPv6 --- Consulting, Training, Projects BIVBlog---Benedikt's IT Video Blog: http://www.stepladder-it.com/bivblog/
Re: [ipv6-wg] IPv6 cloud!
Hi Max and list, Maximilian Wilhelm writes: >> "We have enough IPv4 addresses for ourselves, so this isn't a problem to >> us." > > That's the dumbest and sadly most oftenly heared sentence in this context. that's why I like to quote it... > I had hoped that there were some IPv6 only/broken IPv4 services around > today that would show people that's not the way to go, but I don't > know any. Does anyone have a good example here? That's going to be difficult. If you run a service for money, making it v6only will cost you a lot of market share, so everybody still needs to support IPv4 in that kind of business. You can only expect that on sites run without regard for money by some hyperenthusiastic hobbyists. And frequently enough, enthusiasm is a bad substitute for competence. Things change drastically however if you talk about internal networks. There you can at least sometimes only make the servers dual stacked but connect the bulk mass of clients to either v4 or v6 only. > Even in the educational sector where I work, where we have enough[tm] > money for hardware and tutorials there's no interest in a useful deployment. > Activating v6 in the 5k+ users wifi is delayed (again) for next year, because > it's neither important or urgent. That's the point where I gave up No, don't give up. Try to be nice so they don't hold a grudge against you when the time comes, and then renegotiate your terms. Just make sure they don't blame you for not telling them. Sounds crazy, but that's how people sometimes tick: You tell them to watch out, they ignore you, things blow up in their face, so you should've warned---and protected---them, because after all you already knew beforehand. > What I absolutely fail to grasp is why people don't want to deploy > this v6 stuff while they have a chance to do it without user/customer/ > peer pressure but want to wait until the pressure gets too high. When do people go to the dentist? When they can't stand the pain anymore. Or put differently: "As far as I can tell, everything works for me. So why should I allocate some of my limited resources to this?" >From a technically challenged business perspective it makes perfect sense. In some cases you might reason that fixing your WiFi takes at least three months (or whatever), will be necessary without prior warning, will incur significant extra cost and most importantly, also a loss/reduction of service lasting three months. Or put another way: If you wait until you notice that you're losing money, then you'll lose money. However: In most organizations management has got so used to being lied to with similar claims that they'll simply trust their own "experience". In other words: "As far as I can tell, everything works for me." Makes it rather hard to be heard. Cheers, Benedikt -- Benedikt Stockebrand, Stepladder IT Training+Consulting Dipl.-Inform. http://www.stepladder-it.com/ Business Grade IPv6 --- Consulting, Training, Projects BIVBlog---Benedikt's IT Video Blog: http://www.stepladder-it.com/bivblog/
Re: [ipv6-wg] IPv6 cloud!
Hi Jens and list, Jens Link writes: > Sometimes IT is a world full of surprises and magic. Puff and it > 1999. Oh year 2000 is coming[1]. Puff and the support for Windows XP[2] > ends. Puff and there are only few IPv4 addresses left. Puff and many > access providers are doing some form of large scale NAT and maybe > IPv6. Puff and the solution we bought last year doesn't support > IPv6. But we need IPv6 now. These days, when I'm in the mood and I'm talking to the right people, I simply tell them: "I've decided to focus my work on IPv6 in 2003, and I'm still not sure if it was a smart decision. But the first time I negotiate a four digit hourly rate, then I'll know I was right." Occasionally that seems to get the message home. > About two years ago there was a large German VoIP provider complaining > that all these evil German cable providers had started using IPv6. They > wrote about it in an their BLOG. There were about 70 comments in the > form of "Why don't you just provide IPv6?" Don't forget to mention their statement in that blog that "it's a problem between you and your ISP." Telling that to users who have been switched to DS-Lite (without their ISP even telling them, at least in some cases), and whose "land line" phone stopped working, that's about as good as it gets when you really, really, REALLY want some customers never ever to come back. "*Our* Internet works, so it must be yours that needs fixing!" "We have enough IPv4 addresses for ourselves, so this isn't a problem to us." > There was a lot of time to see that IPv6 is coming. There are still > networking projects today that are not build with IPv6 in mind[3]. And then there are those network projects that claim they support IPv6 but actually only do "IPv4 with longer addresses". But that's the real problem: There's a painful shortage of people who know about networking in general, but with IPv6 it's absolutely hopeless. There aren't even enough people who just memorized enough cookbook recipes they don't understand to get IPv6 (sort of) up and running. Cheers, Benedikt -- Benedikt Stockebrand, Stepladder IT Training+Consulting Dipl.-Inform. http://www.stepladder-it.com/ Business Grade IPv6 --- Consulting, Training, Projects BIVBlog---Benedikt's IT Video Blog: http://www.stepladder-it.com/bivblog/
Re: [ipv6-wg] IPv6 cloud!
Hi Sander and list, Sander Steffann writes: > [DS-Lite starting to hurt on the content side] > > It is starting. I know of one bank that is enabling IPv6 on their > online banking to avoid NAT444/DS-Lite/etc problems. For them the > major problem is that their fraud detection algorithm can't do their > work properly if everybody keeps coming in over CGN. it is indeed. But banks are more IT-savvy and more security aware than most other enterprises, so while the market is growing, it still is surprisingly (and frustratingly) small. But it takes time for the word to spread, and more often than not people mistake IPv6 for the actual problem, rather than IPv4 over DS-Lite etc. >> What I >> find plain weird is that the cloud providers don't realize this as a >> huge chance to get (and lock-in...) customers who need an IPv6 solution >> on short notice. > > I agree. There could be a very nice market for them in the near future > if they would support IPv6. The CDNs seem to have realised this by > now... This is another one of those weird things. The CDNs to my knowledge just got it up and running, but why on earth are the cloud providers lagging behind? With regard to networking they are doing pretty much the same: They host some customers stuff and make sure it is accessible from around the world. Hmm. Cheers, Benedikt -- Benedikt Stockebrand, Stepladder IT Training+Consulting Dipl.-Inform. http://www.stepladder-it.com/ Business Grade IPv6 --- Consulting, Training, Projects BIVBlog---Benedikt's IT Video Blog: http://www.stepladder-it.com/bivblog/
Re: [ipv6-wg] ipv6-wg Digest, Vol 55, Issue 2
Hi Jens and list, Jens Link writes: > Benedikt Stockebrand writes: > >> They used AWS/S3 for some relevant stuff, and since it was done >> externally it wasn't properly QAed. When Amazon switched IPv6 off >> again, they had a little bit of an issue. We only found out kind of >> accidentially, especially so because they didn't want to make it all >> that obvious that they are using Amazon. > > Can't be that relevant if it was not monitored properly. sorry, but I really can't publicly get into the details of that. Let's just say this was the tip of the iceberg, or the trailer of the TV series, or the reason I got so fond of drain cleaner... Cheers, Benedikt -- Benedikt Stockebrand, Stepladder IT Training+Consulting Dipl.-Inform. http://www.stepladder-it.com/ Business Grade IPv6 --- Consulting, Training, Projects BIVBlog---Benedikt's IT Video Blog: http://www.stepladder-it.com/bivblog/
Re: [ipv6-wg] IPv6 cloud!
Hi Dennis and list,
Dennis Lundström writes:
> Not very likely. In most cloud environments I've been exposed to
> Business is the sole-driver to change.
on a more serious note: That wouldn't actually be all bad, but it's the
rather shortsighted manner of doing so.
Considering the increasing reports of people having problems with
DS-Lite I still hope that at some point organizations providing content
(like webshops or such) will realize that they have to go IPv6. What I
find plain weird is that the cloud providers don't realize this as a
huge chance to get (and lock-in...) customers who need an IPv6 solution
on short notice.
Cheers,
Benedikt
--
Benedikt Stockebrand, Stepladder IT Training+Consulting
Dipl.-Inform. http://www.stepladder-it.com/
Business Grade IPv6 --- Consulting, Training, Projects
BIVBlog---Benedikt's IT Video Blog: http://www.stepladder-it.com/bivblog/
Re: [ipv6-wg] IPv6 cloud!
Hi Gert and list, Gert Doering writes: >> I want a drink. And something strong. Like drain cleaner, or at least >> battery acid. > > This will help clean IPv4 out of the clouds? if not that, then what else could we suggest without risking to be told "sir, I suggest you walk" next time you want to fly somehwere? > have you enabled IPv6 on something today...? Shouldn't that be "have you disabled IPv4 on something today...?"? Cheers, Benedikt -- Benedikt Stockebrand, Stepladder IT Training+Consulting Dipl.-Inform. http://www.stepladder-it.com/ Business Grade IPv6 --- Consulting, Training, Projects BIVBlog---Benedikt's IT Video Blog: http://www.stepladder-it.com/bivblog/
Re: [ipv6-wg] what is v6-only?
Hi Vaibhav, Jen, and list, Jen Linkova writes: > On Wed, May 4, 2016 at 7:51 PM, Bajpai, Vaibhav > wrote: >> Hello, >> >> What does v6-only mean? >> >> a) A client only has v6 address and can only route to v6 destinations >> >> b) A client only has v6 address but can route to dual-stack >> destinations using a network translator (such as NAT64) > > From a client perspective, there is no difference between a) and b) - > in both cases the client has no IPv4 address and all communications > happen over IPv6 only. put differently: "v6-only" only makes sense with regard to a specific machine, or set of load-balanced machines, or similar. If you bring in NAT64, forward proxies or similar, then "v6-only" as a term doesn't really make much sense anymore. That said, I'd call the combination of a "v6-only server" and a reverse proxy viewed as a whole dual-stacked. > However there might be additional services provided to allow access to > non-IPv6-enabled destinations. It might be a service provided by the > network (such as NAT64+DNS64) or it might be smth on a host itself > (464XLAT). Don't forget a forward proxy in the DMZ of the user. That's what you almost always find in enterprise environments. Cheers, Benedikt -- Benedikt Stockebrand, Stepladder IT Training+Consulting Dipl.-Inform. http://www.stepladder-it.com/ Business Grade IPv6 --- Consulting, Training, Projects BIVBlog---Benedikt's IT Video Blog: http://www.stepladder-it.com/bivblog/
Re: [ipv6-wg] ipv6-wg Digest, Vol 55, Issue 2
Hi Jens and list, > Seriously. Several people told me "If AWS doesn't offer IPv6 we don't > need IPv6." On the other hand someone told me "our solution for IPv6 > hosting is Amazon. Or some other cloud provider." I had a somewhat similar experience with a customer not too long (not long enough?) ago. They used AWS/S3 for some relevant stuff, and since it was done externally it wasn't properly QAed. When Amazon switched IPv6 off again, they had a little bit of an issue. We only found out kind of accidentially, especially so because they didn't want to make it all that obvious that they are using Amazon. To my knowledge they are still trying to figure out where to move everything to, and how to do such a move seamlessly. Good News[TM] is that this was outside the scope of my responsibilities, but it was still rather frustrating. Cheers, Benedikt -- Benedikt Stockebrand, Stepladder IT Training+Consulting Dipl.-Inform. http://www.stepladder-it.com/ Business Grade IPv6 --- Consulting, Training, Projects BIVBlog---Benedikt's IT Video Blog: http://www.stepladder-it.com/bivblog/
Re: [ipv6-wg] ipv6-wg Digest, Vol 55, Issue 4 -NAT64 Benedikt Stockebrand
Hi Thorsten and list,
Thorsten Trottier writes:
> I’m not a friend of NAT as well, but demonize NAT for any actions is a kind
> of overdo, isn’t it.
> We are living with NAT a long time now for better or for worse.
first off: NAT and NAT64 are two rather different concepts. NAT
translates addresses and ports, but NAT64 translates between
address/protocol families.
> A customer of mine (enterprise customer with hundreds of sites and
> thousands of employees) has setup his IPv6 project more than 4 years
> ago and plans to be finished 2020. [...]
That's a different scenario than the one Christian talked about, which
was more centered around an AD setup.
But anyways: Why didn't you do the updates and made the servers
dual-stacked? If they are too old to support IPv6, then at least from
my experience they are in dire need of an update---or usually a
replacement---anyway.
I understand that using the NAT64 setup buys you some time at least on
some accounts, but from my experience there is pretty much always some
sort of stuff that doesn't work with NAT64 at least in enterprise
environments. And actually finding these things beforehand is quite
some job, so I'd generally consider this move something of a desperate
gamble: Don't properly test because you *really* need a quick kludge,
and hope no major functionalities get affected.
Cheers,
Benedikt
PS: \begin{ObNATBashing}
Anyone who thinks that NAT is no problem should be forced to
implement STUN on any low end SIP phone first and made to deal with
the legal fallout whenever an emergency call didn't work due to STUN
problems second.
\end{ObNATBashing}
--
Benedikt Stockebrand, Stepladder IT Training+Consulting
Dipl.-Inform. http://www.stepladder-it.com/
Business Grade IPv6 --- Consulting, Training, Projects
BIVBlog---Benedikt's IT Video Blog: http://www.stepladder-it.com/bivblog/
Re: [ipv6-wg] ipv6-wg Digest, Vol 55, Issue 2
Hi Jens and list, Jens Link writes: > Benedikt Stockebrand writes: > > Hi, > >>> And may I add cloud providers? >> >> No, you may not. Definitely not. Go away. And take those enterprises >> using them as a cheap CDN with you... > > Well many content providers / startups use "the cloud". No IPv6 there, > no content. Stopitstopitstopitstopit! >> And what's even more frustrating: The Amazon stuff at some time >> supported IPv6 at least on a best effort base, but they switched it off >> again. > > AFAIK only for HTTP(S) Loadbalancing. Which according to some totally unconfirmed rumors was "good enough" for some organization to use as their wannabe CDN. And then Amazon switched IPv6 support off again... I want a drink. And something strong. Like drain cleaner, or at least battery acid. Cheers, Benedikt -- Benedikt Stockebrand, Stepladder IT Training+Consulting Dipl.-Inform. http://www.stepladder-it.com/ Business Grade IPv6 --- Consulting, Training, Projects BIVBlog---Benedikt's IT Video Blog: http://www.stepladder-it.com/bivblog/
Re: [ipv6-wg] ipv6-wg Digest, Vol 55, Issue 2
Hi Jens and list, Jens Link writes: > When I look for example at > https://www.vyncke.org/ipv6status/detailed.php?country=de > I would say many (most?) content providers have to work on IPv6. that's the point. And I still find it difficult to tell people that the increasing number of users stuck behind DS-Lite will actually become a problem to the IPv4-only content providers---at best things will be slower, but at worst they will work less reliably. > And may I add cloud providers? No, you may not. Definitely not. Go away. And take those enterprises using them as a cheap CDN with you... > Last time I checked none of the big players (Amazon, > Google, ...) supported IPv6 in their cloud products. And what's even more frustrating: The Amazon stuff at some time supported IPv6 at least on a best effort base, but they switched it off again. Cheers, Benedikt -- Benedikt Stockebrand, Stepladder IT Training+Consulting Dipl.-Inform. http://www.stepladder-it.com/ Business Grade IPv6 --- Consulting, Training, Projects BIVBlog---Benedikt's IT Video Blog: http://www.stepladder-it.com/bivblog/
Re: [ipv6-wg] ipv6-wg Digest, Vol 55, Issue 2
Hi folks, sorry for the late reply, but now that Jen is back I've taken a couple days off myself. Sander Steffann writes: >> Op 25 apr. 2016, om 19:35 heeft Silvia Hagen het >> volgende geschreven: >> >> That would be a great panel discussion with some diverse speakers on the >> panel :-) > > I have been doing some enterprise stuff as well recently. If there is > going to be such a panel I would love to participate! :) Unless Jen somehow scares away various speakers (and I guess that's something she's *not* going to be particularly successful with:-) our schedule is already pretty full. Otherwise, I heartily agree. IPv6 is currently changing from an ISP issue to an enterprise and (especially small to medium) content provider issue. And if I've learned anything the last two years, then that this opens a completely different can of worms. Maybe we can do that panel discussion in Madrid(?) Cheers, Benedikt -- Benedikt Stockebrand, Stepladder IT Training+Consulting Dipl.-Inform. http://www.stepladder-it.com/ Business Grade IPv6 --- Consulting, Training, Projects BIVBlog---Benedikt's IT Video Blog: http://www.stepladder-it.com/bivblog/
Re: [ipv6-wg] ipv6-wg Digest, Vol 55, Issue 2
Hi Christian and list, christian bretterhofer writes: > I think the basic work for ISPs in concern to IPv6 is covered. well, depends on the ISP in question. To me it looks a lot like many are still struggling to get the necessary knowledge and experience to their tech and support crowd---not necessarily with the people actively involved in the RIPE community, but at least with the big ones. A customer recently asked one of the large players here in Germany if they were interested in a contract that would have allowed my customer to outsource some IPv6-related tasks---or rather, to outsource some tasks that were also expected to be supported via IPv6. They were turned down with the explanation "we don't have the necessary manpower to operate this". > But i miss the topics to be addressed if you want to migrate from a > IPv4 Microsoft Active domain using company to an system where most > server in an enterprise could by just IPv6 only and use technologies > like NAT46 ( SIIT-DC ) or similar to still make IPv4 only windows > clients happy. Now I've taken a bit of a look at these things, but then I'm not exactly a Microsoft guy. From all I've seen, going for NAT64 and such is generally a bad idea. Instead, ensure that IPv6 is provided wherever it is needed and then make your servers dual stacked. Yes, that frequently involves upgrades on various servers nobody really wants to touch, but the very reasons why nobody wants to touch them are the reasons why you actually clean that stuff up. > Switching an enterprise with location around the global from a "we > donot route any IPv6 traffic across our WAN Links" "most servers have > IPv6 disabled" to > We start IPv6 routing partially and enable partial IPv6 support on > servers in a Microsoft ADS environment seems not covered in most IPv6 > covering websites and presentations. That may be because your approach is unnecessarily painful. You want to get IPv6 up and running in the network infrastructure first, then make your servers dual-stacked and then deal with the clients. At least that's the "strategic" outline of an approach. Beyond that it's really a lot of detail work to do on an individual basis. > Maintaining dual stack for the datacenters is just painfull and there > should be a "single" device in the form of NAT46/SIIT/SIIT-DC in front > of each server area. I am not sure that Active directory is ready for > that. Nonononono, don't do that. Whenever something goes wrong with that "single device", you'll have a serious disruption of service, not everything works through it, and you'll never ever get a chance to get rid of it in the long run because there'll always be that one last server that depends on it, or might depend on it but nobody knows for sure. Yes, that means that you need to have all your servers dual stacked, and yes, that's some serious extra workload in a data center context, but anything else is quite likely way worse. Cheers, Benedikt -- Benedikt Stockebrand, Stepladder IT Training+Consulting Dipl.-Inform. http://www.stepladder-it.com/ Business Grade IPv6 --- Consulting, Training, Projects BIVBlog---Benedikt's IT Video Blog: http://www.stepladder-it.com/bivblog/
Re: [ipv6-wg] RIPE72 IPv6 WG: call for presentations
Hi Yannis and list, Yannis Nikolopoulos writes: > the list has been awfully quiet lately... that's right, but I guess in the RIPE community the word has spread to the point that basic questions about IPv6 simply don't need to get asked here that much anymore. > I see that there are 2 slots for the WG but I couldn't find the > programme That's because we are still working on it. We have two slots allocated to us and it doesn't look anything like we'll be heading to the coffee break early, and submissions still come in. As soon as Jen returns to the inhabited world (i.e. with Internet access) we'll see how we can fit everything into those slots and then send out the agenda. Cheers, Benedikt -- Business Grade IPv6 Consulting, Training, Projects Stepladder IT Training+Consulting GmbH Benedikt Stockebrand Fichardstr. 38, 60322 Frankfurt/MainDipl.-Inform./Geschäftsführer HRB 94202, Registergericht Frankfurt/M cont...@stepladder-it.com http://www.stepladder-it.com/ +49 (0) 69 - 247 512 362 http://www.benedikt-stockebrand.de/ +49 (0) 177 - 41 73 985 BIVBlog---Benedikt's IT Video Blog: http://www.stepladder-it.com/bivblog/ Bitte kein Spam, keine unaufgeforderten Werbeanrufe, keine telefonischen Umfragen. Anrufe werden ggf. zu rechtlichen Zwecken aufgezeichnet. No spam, no unsolicited sales calls, no telephone surveys, please. Calls may be recorded for legal purposes.
Re: [ipv6-wg] IPv6-only network during RIPE 71
Hi Sander, Marco, and list, Sander Steffann writes: > Hi Marco, > >> At the moment the actual capacity of the NAT64 network is not >> known. This means we cannot offer any guarantees on throughput or >> the number of simultaneous connections supported. Marco, you still sound like a corporate lawyer:-) >> Meanwhile, we will gather some basic information such as number of >> clients connected to the network. Some RIPE NCC staff might use this >> opportunity to run tests as well. We encourage the community to keep >> track of any issues reported and to document them together with >> possible solutions. > > This bit disappoints me a bit. [...] Come on, Sander. The NCC ops folks (Razvan and his lot) aren't exactly having a paid vacation trip during a RIPE meeting; they usually look just as tired as everybody else on friday, so asking for an unpredictable extra workload isn't exactly fair. It's not like I wouldn't love to hear the announcement during the opening plenary that IPv4 is only available wired from a single switch located in the terminal room, but looks like we'll have a couple rounds of nagging to do. What I'd like to see, and that's well in line with what Marco wrote, is that we see if we can make as many people as possible actually try the IPv6 network out. No longer calling it "experimental" really is an important step here; talking about this during the opening plenary is even more important. Rather than just telling the ops folks what to do or not I really suggest we help them get the data they need to do the next step, which is to convince as many people as possible to use the IPv6 network and then give any feedback they can come up with. Oh, and one more thing: We might ease things up for ops if we actually managed to point out during the opening plenary that people with IPv6 stickers on their badges are generally volunteering as experimental^Winofficial first level IPv6 support... @Nick: Can we do something about getting maybe 3 minutes worth of time during the monday plenary for this, or could somebody from the regular staff do such a quick announcement for us? Cheers, Benedikt -- Benedikt Stockebrand, Stepladder IT Training+Consulting Dipl.-Inform. http://www.stepladder-it.com/ Business Grade IPv6 --- Consulting, Training, Projects BIVBlog---Benedikt's IT Video Blog: http://www.stepladder-it.com/bivblog/
Re: [ipv6-wg] IPv6-only network during RIPE 71
Hi list,
so far I've tried to stay out of this thread and do this face to face in
Bucharest, but well...
As I've said and written before, the responsibility for the operation of
the network is with the NCC technical team, and as such it should really
be their call when to change what. And I really appreciate Marco being
extra careful with his wording (even if it reads like it's been written
by a lawyer:-)
On the other hand, I think it is our (as a WG) job to keep nudging them
towards what the eventual outcome should be (which is an IPv6 only WLAN
with as much IPv4 as there is IPX, SNA, or UUCP...).
Maybe we can come to some sort of outline on how to get there during the
meeting? After that we can then argue about actual timing without
getting lost in the fog of detail.
Cheers,
Benedikt
--
Benedikt Stockebrand, Stepladder IT Training+Consulting
Dipl.-Inform. http://www.stepladder-it.com/
Business Grade IPv6 --- Consulting, Training, Projects
BIVBlog---Benedikt's IT Video Blog: http://www.stepladder-it.com/bivblog/
Re: [ipv6-wg] Promote the use of IRC
Hi spz and list,
"S.P.Zeidler" writes:
>> In other words, we need somebody to step forward and take on that duty.
>
> Unrealistic. Even if you had someone whose job it was to monitor the
> channel, they can hardly be expected to be even awake 24x7.
Exactly, and just the same for three WG chairs.
So if we don't find anybody (anybodies???) to take care of that, then
setting up an "official" RIPE IPv6 IRC channel is rather likely to
render the decision making process in the WG useless.
> From my experience with other organisations that work through mailing
> lists and also have chat venues, treating the chat(s) as equivalent to
> "we were chatting over dinner", i.e. as slightly more refined discussion
> starts on the binding communication channel, is the only thing that works.
That's the point: We need to make sure that this understanding is well
established, and especially so when an informal discussion turns to
something relevant to the list; for that we need somebody to tell people
"please move this over to the mailing list" at some point.
Otherwise we wind up with situations I've seen elsewhere: "We don't need
to discuss it here yet again, we've done so {over dinner and a beer last
night|in another mailing list|in the IRC channel|...}". And I've seen
that elsewhere and know from first-hand experience that is dedicedly
counterproductive.
>> If we establish that IRC channel, then we must find a way---and the
>> resources---to ensure this.
>
> Eh, preventing people from talking to each other is hard, especially if
> they all have Internet. :) (Never mind the occasional barbeque)
I don't want people to prevent from talking, but I want to make sure
that people who are interested in participating in a discussion actually
get a chance to do so, and without excessive waste of time.
Cheers,
Benedikt
--
Benedikt Stockebrand, Stepladder IT Training+Consulting
Dipl.-Inform. http://www.stepladder-it.com/
Business Grade IPv6 --- Consulting, Training, Projects
BIVBlog---Benedikt's IT Video Blog: http://www.stepladder-it.com/bivblog/
Re: [ipv6-wg] Promote the use of IRC
Hi yet again,
Dave Wilson writes:
> I need to speak a little about a working group chair's duties, so I kind
> of have to wear that hat, but please consider this as a voice in the
> discussion and not a chair's influence on it.
now that you mention it: Same thing with me.
> [Making a consensus call]
> At this moment, if I knew there was a supported venue where policy
> discussion was taking place, it's not clear to me if I would be expected
> to chair and monitor the discussion there, [...]
According to David's original mail:
DB] For this list, an #ipv6 channel will be created and administrated by
DB] the WG Chairs.
This is completely infeasible with three volunteer WG chairs. (And I've
personally worked long enough in an industry where people pile up
additional work on you any chance they get to be rather wary of this.)
If we have this IRC channel, and if it turns out that decicion-related
discussions start to move there, then *somebody* *must* be there to send
them in the proper direction, i.e. to the mailing list. And again, that
can't possibly be the job of a WG chair.
In other words, we need somebody to step forward and take on that duty.
> But this is a solveable problem. We do it at RIPE meetings - we take
> minutes at the meetings, which are published to the list, and frequently
> remind ourselves that decisions are taken on the list.
While you mention the meetings: We only have a rather limited time slot
there; cleaning up half a years worth of miscommunications through
unsynchronized channels is definitely not going to happen in five
minutes.
> And if some of us
> talk about policy amongst ourselves, over dinner say, then we know that
> as far as the discussion and consensus is concerned, "if we don't take
> it to the list, it didn't happen."
>
> So how would that be solved in the case of a live chat discussion?
There is only one answer to that: If it is about policy, or decision
making, or whatever you want to call it, then it *must* stay on the
mailing list.
If we establish that IRC channel, then we must find a way---and the
resources---to ensure this.
Cheers,
Benedikt
PS: And then there's another question, that I can't personally answer:
If we keep all decision related discussions to the mailing list
anyway, then what about existing IRC channels that already cover the
rest? I personally stay away from IRC (it's incompatible with my
line of work) so I'm not up to date on this, but if I remember
correctly there is at least one channel entirely devoted to IPv6
operations independent of RIPE.
--
Benedikt Stockebrand, Stepladder IT Training+Consulting
Dipl.-Inform. http://www.stepladder-it.com/
Business Grade IPv6 --- Consulting, Training, Projects
BIVBlog---Benedikt's IT Video Blog: http://www.stepladder-it.com/bivblog/
Re: [ipv6-wg] Promote the use of IRC
Hi again... "Niall O'Reilly" writes: > I agree with what Jim Reid posted on another list in response to the > same question. > > > https://www.ripe.net/ripe/mail/archives/address-policy-wg/2015-August/010523.html > > Specifically: "Put bluntly, if a discussion about any WG matter does > not take place on the mailing list, it simply didn't happen." now that was on the address policy WG list, which is pretty much diametrically opposite in nature to the IPv6 WG since it is all about policy, while the IPv6 WG isn't about policy at all. But Jims general reasoning is perfectly right. It's already difficult enough to keep things in the proper channel: So far we've had one discussion on AP WG list on disbanding the IPv6 WG list, and somehow I've got the feeling that this discussion started on the RIPE *NCC* members list while it concerns a RIPE (*non-NCC*) WG. It may be reasonable to have a "more realtime" channel for questions that aren't exactly relevant to the WG as such, like "Is it OK to use a /96 subnet prefix?"[1], but if this leads to making it impossible to keep track of the discussions on a topic in their entirety, then we'll have a real problem, because we'll have to sort out all kinds of misunderstandings and whatnot at the RIPE meetings. Cheers, Benedikt [1] See RFC 4291, Section 2.5.1, third paragraph... -- Benedikt Stockebrand, Stepladder IT Training+Consulting Dipl.-Inform. http://www.stepladder-it.com/ Business Grade IPv6 --- Consulting, Training, Projects BIVBlog---Benedikt's IT Video Blog: http://www.stepladder-it.com/bivblog/
Re: [ipv6-wg] Promote the use of IRC
Hi Daniel and list, "Daniel Baeza (Red y Sistemas TVT)" writes: > Yesterday, I've started a discussion in the member list about exactly which list are you writing about? > promoting the use of IRC instead of Mail List for some kind of > discussions, chit chat, etc. > > Not much members answered, but all who did said yes. Hmm, from what I've seen in the community here, that doesn't really mean much. If people don't respond it can mean they agree (and wait for a consensus call to keep the noise down) and it can also mean they consider the idea a complete waste of time (and wait for a consensus call to keep the noise down). The problem I see with discussions per IRC is that a lot of us work in the kind of job where we can't keep hanging around in the IRC; or put bluntly, every once in a while I find it impossible to ensure I catch up on the list every evening. So moving discussions and possibly even decision making to the IRC will effectively keep people like me out of that discussion. > The goal is to have, at least, one channel per mail list, but not > limited to only that. > > For this list, an #ipv6 channel will be created and administrated by > the WG Chairs. Hmm, have Dave and/or Jen agreed to take care of that job? If so, then fine, but I can't possibly take on that job myself. And I'm most definitely not spending time on trying to catch up with discussions by reading whatever transcripts every night or so. Which leads to another problem: While there are a lot of people who write e-mails faster than they think, those people are reasonably rare in this community; but IRC leads to much more noise, which adds a lot of unnecessary work. Cheers, Benedikt -- Benedikt Stockebrand, Stepladder IT Training+Consulting Dipl.-Inform. http://www.stepladder-it.com/ Business Grade IPv6 --- Consulting, Training, Projects BIVBlog---Benedikt's IT Video Blog: http://www.stepladder-it.com/bivblog/
Re: [ipv6-wg] Implications of NAT/NAT64 and similar
Hi Silvia and list, Silvia Hagen writes: > Transition mechanisms have the attribute of being transitional by > definition. So they bridge gaps. That is exactly what NAT was > originally designed for - bridge a gap until real solution is at hand. > [...] yes, but they also have another effect: They make people believe that the problem is solved, often leading to a situation where these stopgap measures don't work any longer and the pressure to fix the problem is *really* bad. Or, in a different context: As long as the painkillers work, why should I go to the dentist? Only when the workaround is more painful than the problem it solves, then people start to move. We see that with DS-Lite, which is why I called it so useful at the RIPE meeting in Amsterdam: To the ISPs and the content providers, and increasingly to the enterprises too, it is simply less painful to go server side dual-stack than deal with the collateral damage caused by IPv4-only on their side and DS-Lite on their users. > So let's hope we learned from the NAT issue Seriously, I doubt that; this behaviour is too deeply entrenched in peoples minds. And while we're both making a living out of IPv6, it's still a niche market for people like us; if people had learned, then we'd be drowning in project offers. > We live in a free world and the Internet is VERY diverse. > What is good for the ones is bad for others. Fully agree on that. And it's rather difficult to come up with ideas or approaches that won't cause significant problems for others. But that's exactly why I point out the problems NAT causes to other people. > I do not believe in IETF or whoever else dictating the market how to > do it. Hmm, I guess there are a number of people at the IETF who'd be quite seriously offended by that statement, but anyway: One of the most fundamental goals of the Internet and the technologies used there is interoperability. I still remember how Compuserve and AOL and MSN and various others tried to establish their proprietary internetworking products, and people eventually opted for the Internet largely because of its interoperability. The role of the IETF is to ensure that specifications (not standards by the way, but that's yet another issue:-) support this interoperation. > I think we should offer different transitional solutions solving > different issues and let the actors in the market decide, what > combination works best for them. Yes, but: If the "market decides" then there's a good chance that people will sacrifice that interoperability for their own advantage. There are some people who benefit from full-blown NAT66, but others will then have to pay the price (STUN, reduced reliability, increased operational expenses, extra hardware, ...). One of the problems with transitional solutions, aside from delaying the inevitable until it really hurts, and always lasting forever, is that each increases complexity. And considering how difficult it is to recall those solutions when once made available. Which leads back to the extension header issue... Cheers, Benedikt -- Benedikt Stockebrand, Stepladder IT Training+Consulting Dipl.-Inform. http://www.stepladder-it.com/ Business Grade IPv6 --- Consulting, Training, Projects BIVBlog---Benedikt's IT Video Blog: http://www.stepladder-it.com/bivblog/
Re: [ipv6-wg] Extension Headers / Impact on Security Devices
Hi Silvia and list, Weekend:-) Anyway: Silvia Hagen writes: > I keep stumbling about that "recommendational wording" in RFC 2460 everytime > I teach it. So do I. The problem underneath however is anything but trivial. > Couldn't we update RFC2460 and make this list a strict order? As I understand it the way extension headers work was effectively a response to the severe limitations of header options in IPv4 (like 60 octets max, not even enough to do a proper record route option). The reason for the rather relaxed wording here is in all likelyhood that people at that time didn't want to impose any rules cast in stone which would later on turn out to be another similar limitation; for example, if a subsequently defined extension header was specified, it would be rather difficult to retrofit. However, with the experience we have with extension headers so far I guess you're right, it is likely time to investigate the possibility to make the ordering and such mandatory. That will allow for much better hardware implementations, if nothing else. > I would want my firewall to notify me if the EHs in a packet do not follow > the list. > And limiting the number of possible EHs per packet might be a good idea. Right, but there are a number of differences between a firewall and a high end router, so this should really be investigated from a wide range of perspectives, from microcontroller based embedded devices to high end routers, and from consumer-managed home environments to high security environments. This is quite likely a pretty big job. Cheers, Benedikt -- Benedikt Stockebrand, Stepladder IT Training+Consulting Dipl.-Inform. http://www.stepladder-it.com/ Business Grade IPv6 --- Consulting, Training, Projects BIVBlog---Benedikt's IT Video Blog: http://www.stepladder-it.com/bivblog/
Re: [ipv6-wg] Implications of NAT/NAT64 and similar
Hi Dan and list,
🔓Dan Wing writes:
> On 15-May-2015 02:25 am, Benedikt Stockebrand wrote:
>> [Implications of NAT64]
>
> To avoid some of that, they can go IPv6-only, including their servers
> and all peers they communicate with, then there doesn't need to be
> NAT64 for their traffic. But even IPv6-only they will need firewall
> traversal support, as firewalls by default will block unsolicited
> incoming traffic (RFC6092).
I'm not sure if I get you correctly, but: Do you mean IPv6 only, or
dual-stacked servers (so whatever a client connects with works without
translation)?
Cheers,
Benedikt
--
Benedikt Stockebrand, Stepladder IT Training+Consulting
Dipl.-Inform. http://www.stepladder-it.com/
Business Grade IPv6 --- Consulting, Training, Projects
BIVBlog---Benedikt's IT Video Blog: http://www.stepladder-it.com/bivblog/
Re: [ipv6-wg] Implications of NAT/NAT64 and similar
Hi Silvia and list, Silvia Hagen writes: > Hi Benedikt > > But in combination with 464XLAT it seems to do the job well enough to > support millions of IPv6-only users for T-Mobile. And thereby allows > them to deploy v6-only at the edge, where address consumption is > highest. > > So maybe it would be good to differentiate a bit more and not throw > out the baby with the bathwater. fair enough, but even then 464XLAT is a transition technology which following your reasoning causes a long term problem that software developers can't rely on end-to-end connectivity even with IPv6. In other words, while it helps in the short term, we'll pay dearly for it in the long run. Yes, of course you are right that this is a complex issue, but there's a widespread tendency to carry the old limitations of today's IPv4 to IPv6 even if there's no real need to do so. And Marc calling NAT64 a working solution despite the fact that it breaks IPv6 the same way NAT broke IPv4 really asks to be balanced by a similarly oversimplified statement going the other way:-) So the real question is: How do we deal with exactly that risk, i.e. that some transition technologies burden the IPv6 world with otherwise unnecessary legacy issues? Cheers, Benedikt -- Benedikt Stockebrand, Stepladder IT Training+Consulting Dipl.-Inform. http://www.stepladder-it.com/ Business Grade IPv6 --- Consulting, Training, Projects BIVBlog---Benedikt's IT Video Blog: http://www.stepladder-it.com/bivblog/
Re: [ipv6-wg] Extension Headers / Impact on Security Devices
Hi Enno and list, Enno Rey writes: > hope everybody had a great #RIPE70 meeting. We did! > Many thanks to the organizers and chairs! and thanks to the actual speakers as well the speakers we had to turn down due to time constraints, too:-) > If the chairs consider this appropriate we will happily give a > presentation on this stuff in Bucharest or at another occasion. Sounds good to me! > - looking at the "liberty" RFC2460 provides as for ext_hdrs (wrt to > their number, order[...] Actually, as far as I'm concerned that's the real core of the problem. Or more specifically, the first two lines of RFC 2460, section 4.1: When more than one extension header is used in the same packet, it is recommended that those headers appear in the following order: followed on the next page by Each extension header should occur at most once, except for the Destination Options header which should occur at most twice (once before a Routing header and once before the upper-layer header). Note in particular that these are not even RFC 2119 "SHOULD" or "RECOMMENDED" and such. The impact here is actually at least twofold: - It is impossible to implement this as a simple pipeline architecture in hardware; at least for cases deviating from the "recommendations" above this effectively becomes either excessively complex to implement in hardware or an invitation to DoS when implemented in software on an otherwise hardware router. - As I understand it, at least some of the issues you have found are effectively based on violating the second paragraph quoted, making it impossible to come up with a lower bound on how long the header chain can actually get and therefore leading to the fragmentation related attacks and similar you have discovered. The original idea was that the extension headers are processed strictly in the order they occur, so one question to ask is if there is any valid reason to violate these "recommendations" for other than malicious purposes. Cheers, Benedikt -- Benedikt Stockebrand, Stepladder IT Training+Consulting Dipl.-Inform. http://www.stepladder-it.com/ Business Grade IPv6 --- Consulting, Training, Projects BIVBlog---Benedikt's IT Video Blog: http://www.stepladder-it.com/bivblog/
[ipv6-wg] Implications of NAT/NAT64 and similar (was: Re: IPv6 only as default for next meeting)
Hi folks, this is admittedly a pet peeve of mine, so apologies right in advance to anybody getting offended by this, but I'd like to rephrase "Marc Blanchet" writes: > I think the technology (v6only-nat64-dns64) is mature enough. The > problem is that various applications and services are not compatible > with it (usually IPv4 addresses negotiated in the payload) as this: I think the technology (v6only-nat64-dns64) is inherently broken by design. By design it doesn't support a range of important and widely used existing applications and services that it should be compatible with to be considered "working". With NAT, NAT64 or whatever other application unaware translation hack being around, a lot of extra complexity is pushed towards the application layer. NAT* doesn't solve any problems, it just puts the burden on others who is unlikely in a situation to defend themselves (the app. developers) ; the overall effect is counterproductive. Aside from that, once we talk not full-blown computers but embedded devices, adding support for NAT penetration (STUN or whatever) is a major problem. The original Arduino uses a microcontroller with 32KB of flash (for program code) and 2KB of RAM, and that's already a fairly big one. Adding STUN support there is a serious problem. Again, this isn't meant as a flame or anything, but to show that these technologies have serious implications for others. Cheers, Benedikt -- Benedikt Stockebrand, Stepladder IT Training+Consulting Dipl.-Inform. http://www.stepladder-it.com/ Business Grade IPv6 --- Consulting, Training, Projects BIVBlog---Benedikt's IT Video Blog: http://www.stepladder-it.com/bivblog/
Re: [ipv6-wg] [atlas] What to do with RIPE Atlas probes that have only a ULA as IPv6 address?
Hi folks, Jen Linkova writes: >> So the question to the community, should RIPE Atlas treat ULAs in the >> same way as RFC-1918, addresses that should be ignored unless a valid >> global address can be found elsewhere. Or should we keep the current >> approach where ULAs are treated just like other global IPv6 addresses >> and consider the probe host's network setup to be broken? > > But wait, if a probe has RFC1918 addresses only you do not mark it as > 'no v4 connectivity', right? > If a probe has a address of a global scope (v4 or v6) but could not > reach the outside world it means the connectivity is broken. So IMHO > it makes slightly more sense to mark ULA-only probes as having broken > connectivity. just wondering: If I use RFC1918 addresses with IPv4 I might still have Internet access through a NAT gateway. If I have only ULA, then I may reasonably expect there's no NAT, so there's a fundamental difference here. However, I personally *do* run my stuff through a firewall setup including application level gateways. So it might be argued that my ULA-only devices still have (some rather limited sort of) Internet access anyway. Cheers, Benedikt -- Benedikt Stockebrand, Stepladder IT Training+Consulting Dipl.-Inform. http://www.stepladder-it.com/ Business Grade IPv6 --- Consulting, Training, Projects BIVBlog---Benedikt's IT Video Blog: http://www.stepladder-it.com/bivblog/
[ipv6-wg] Call for Presentations
Hi folks,
since the call for presentations for the plenary sessions of RIPE 70 on
May 18--22 in Amsterdam (https://ripe69.ripe.net) is already out (see
https://ripe70.ripe.net/submit-topic/submission-form/) we'd like to ask
anyone interested in doing "anything" (presentation or whatever else,
I'll just write "presentation" from here on) during the working group
session to send us your proposal.
A couple of notes about the procedure:
- There is no formal submission mechanism as with the plenary/program
committee. Just drop a mail to ipv6-wg-cha...@ripe.net and if we
have any questions we'll contact you.
- We're interested in pretty much anything related to IPv6, including
deployment, operation, further development and whatever you think
might be of interest to the working group.
- If you're unsure about proposing your presentation to the plenary or
the IPv6 working group, I suggest you submit it to the plenary
through the link mentioned above and send us an e-mail in parallel;
that way we have a better chance to make sure that topics too
esoteric for the plenary may actually find their niche in the
working group, rather than being lost forever.
- What we do need are:
- Your name and (at least) e-mail address
- The (preliminary) title of your presentation
- A (preliminary) abstract (a paragraph or two)
- A short bio of yours
- The time you roughly expect to need <=== IMPORTANT:-)
- Whatever questions you have
- We need to have an idea how much time we need for the working group
session, so we can request an additional time slot from the NCC if
needed. So please, send us at least a preliminary draft as soon as
possible; you can always polish your proposal up afterwards.
- And, as Filiz pointed out in the call for presentations for the
plenary: "Please also note that speakers do not receive any extra
reduction or funding towards the meeting fee at the RIPE Meetings."
Cheers,
Benedikt (with blessings from Jen and Dave)
--
Benedikt Stockebrand, Stepladder IT Training+Consulting
Dipl.-Inform. http://www.stepladder-it.com/
Business Grade IPv6 --- Consulting, Training, Projects
BIVBlog---Benedikt's IT Video Blog: http://www.stepladder-it.com/bivblog/
Re: [ipv6-wg] [address-policy-wg] [Merging ipv6 and address policy mailing lists]
Hi folks,
Jen Linkova writes:
> On Wed, Nov 12, 2014 at 8:32 AM, Aleksi Suhonen
> wrote:
> [...]
>>In practice, I do think that a separate mailing list for
>> IPv6 at RIPE has outlived its usefulness.
> [...]
> There are a lot of topics to discuss on IPv6 WG which do not belong to
> address policy.
I fully agree with Jen here.
If I take a look at last week's IPv6 WG session in London (agenda and
video at https://ripe69.ripe.net/programme/meeting-plan/ipv6-wg/) I
don't see *anything* there actually related to address policy.
@Aleksi: Maybe you could explain *why* you "think that a separate
mailing list for IPv6 at RIPE has outlived its usefulness" at this
point?
> Anyway, I'm surprised to see a discussion about shutting down a
> mailing list happening in *another* mailing list.
> [...]
I also consider this approach rather rude, but I guess we should still
try to keep such matters of style separate from the actual topic at
hand.
In any case, discussion on shutting down the IPv6 WG mailing list
obviously doesn't belong on the address policy WG list; it would be a
decision to be made in the IPv6 working group.
That said, if I was more involved with the address policy WG, I'd also
expect to get involved if someone proposed to dump some other WG
discussions into "my" mailing list. If you want to see something
similar (albeit "backwards") having happened in the past, take a look at
the IETF V6OPS WG mailing list before they forked SUNSET4.
> I'm adding ipv6-wg@ to Cc: so people are aware of this discussion,
Thank you, Jen!
As far as I'm concerned, I do archive the address policy WG, but I don't
generally follow it. And I've got a strong impression that there are
others who actively monitor the IPv6 list but don't even archive the
address policy list.
> however from my point of view we've seen enough support to keep IPv6
> list untouched.
So do I.
\begin{wg-chair-mode}
To deal with this question properly I suggest we follow a two step
approach:
- First we see *on the IPv6 WG mailing list*---and please set the rcpt
accordingly---if there is some sort of consensus to propose a merger
with the address policy WG list.
- If that consensus is actually reached, then as the second step the
address policy WG should decide if they actually agree with our (IPv6)
discussions moving there.
I haven't had time to talk about this with Jen and Dave directly, but as
far as I'm concerned if there is no further discussion on this on the
IPv6 mailing list, I'll consider that as consensus with Jen's statement
and assume the question settled.
\end{wg-chair-mode}
Cheers,
Benedikt
--
Benedikt Stockebrand, Stepladder IT Training+Consulting
Dipl.-Inform. http://www.stepladder-it.com/
Business Grade IPv6 --- Consulting, Training, Projects
BIVBlog---Benedikt's IT Video Blog: http://www.stepladder-it.com/bivblog/
