Re: [ipv6-wg] Microsoft Support for IPv6-Mostly networks
On Fri, Mar 8, 2024 at 7:35 AM Rinse Kloek wrote: > That someone was me :) Ah good, glad you see this email then ;) >Thanks for the information, seems that > IPv6-mostly is now really well adopted on most clients. "is now adopted" is an overstatement still - that blog post is announcing the confirmed plans, not the existing implementations, but at least networks with Windows clients can start planning now. > On 7-3-2024 20:48, Jen Linkova wrote: > > After my IPv6-mostly talk at RIPE88 plenary someone asked me: what > > about Windows? > > So, there is some light at the end of the tunnel: > > > > https://techcommunity.microsoft.com/t5/networking-blog/windows-11-plans-to-expand-clat-support/ba-p/4078173 > > > > > -- > > 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 -- Cheers, Jen Linkova -- 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
[ipv6-wg] Microsoft Support for IPv6-Mostly networks
After my IPv6-mostly talk at RIPE88 plenary someone asked me: what about Windows? So, there is some light at the end of the tunnel: https://techcommunity.microsoft.com/t5/networking-blog/windows-11-plans-to-expand-clat-support/ba-p/4078173 -- Cheers, Jen Linkova -- 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] [ipv6-wg-chair] Call for IPv6 WG Co-Chair candidates
The chairs would like to thank those who have already volunteered and ask those who are going to volunteer to email the charis (mailto:ipv6-wg-chair at ripe.net) and not the list. Thank you and see you all in Krakow! On Fri, Mar 1, 2024 at 11:53 PM Raymond Jetten wrote: > > Dear IPv6 Working Group, > > > > Jen Linkova, who has been one of the co-chairs of the IPv6 Working Group > since RIPE 69 > > has announced she wishes to step down at the RIPE 88 meeting in Kraków, at > the end of her term. > > > > Thus, we have a call for candidates. > > The term of a IPv6 WG co-chair is three years. A current co-chair may stand > for > > re-selection at the end of their term or may resign voluntarily at any time. > > > > What is the IPv6 WG doing: > > The working group activities may be anything useful in helping people to > deploy IPv6, > > and to manage IPv4/IPv6 co-existence. These activities include: > > > > Outreach > > Education > > Sharing deployment experiences > > Discussing and fixing operational issues > > > > The co-chairs also prepare the program for the IPv6 WG session at the ripe > meetings. > > > > The working group will cooperate with operators and others, both inside and > outside the > > networking industry, to share resources and combine efforts. > > > > The tasks and expectations of a WG co-chair are described here: > > https://www.ripe.net/publications/docs/ripe-692 > > > > A WG co-chair must comply with the Code of Conduct: > > https://www.ripe.net/publications/docs/ripe-766 > > > > If you feel you are interested in this or have any questions on this, you can > drop the current > > co-chairs a note ipv6-wg-chair at ripe.net mailto:ipv6-wg-chair at ripe.net > > We kindly request you to respond at latest Friday 3-May-2024 midday CET > (Amsterdam), > > when the call for candidates will be closed. > > > > After this we will announce the candidates on the list, and you can express > your support or concerns. > > However the official selection will take place at the RIPE 88 Meeting in > Kraków during the IPv6 Working Group session. > > > > On behalf of the IPv6 WG co-chairs, > > > > Ray > > RIPE IPv6 Working Group co-Chair > > To the co Chairs: ipv6-wg-chair at ripe.netmailto:ipv6-wg-chair at ripe.net > > To the mailing list: ipv6-wg at ripe.netmailto:ipv6-wg at ripe.net > > > > > For Internal Use Only -- Cheers, Jen Linkova -- 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
[ipv6-wg] IPv6 WG chair 2021 re-selection
Hello, My 3 years term as the IPv6 WG co-chair will be over after RIPE82, so the call for the candidates is open. I'd like to stand for re-selection as well, volunteering to serve another term. If you'd like to volunteer or nominate someone (or just make a comment ;), please send an email to the list (or respond to this thread). The closing date for candidates will be Sunday, May 16th 2021, 23:59:59 UTC. The WG chair selection will happen during the IPv6 WG session @ RIPE82 (currently scheduled for May 20th, 10:30am CEST time zone (UTC+2) Thank you! -- SY, Jen Linkova aka Furry
[ipv6-wg] IPv6 WG @ RIPE81 Agenda
The agenda for the IPv6 WG session at RIPE81 has been published: https://ripe81.ripe.net/programme/meeting-plan/ipv6-wg/ Thanks to everyone who submitted a talk - this time we got really overbooked so my apologies if your talk was not accepted! See you in 3 weeks! -- SY, Jen Linkova aka Furry
Re: [ipv6-wg] IPv6 WG@RIPE81: Call for Presentations
On Wed, Sep 9, 2020 at 5:42 PM Jen Linkova wrote: > RIPE81 will be virtual, from Oct 27th till Oct 30th. IPv6 Working > Group is tentatively scheduled for Oct 29th, 13:00 - 13:45. > > We are looking for talks - please email ipv6-wg-ch...@ripe.net if > you'd like to present. Surprisingly we are still looking for talks! I'm wondering if the silence means that nobody is doing IPv6 in the times of COVID? Or is everyone so busy with rolling out IPv6 finally? Either way, come and tell us your story! The deadline for submissions is Sep 28th. Thanks! -- SY, Jen Linkova aka Furry
[ipv6-wg] IPv6 WG@RIPE81: Call for Presentations
Hello, RIPE81 will be virtual, from Oct 27th till Oct 30th. IPv6 Working Group is tentatively scheduled for Oct 29th, 13:00 - 13:45. We are looking for talks - please email ipv6-wg-ch...@ripe.net if you'd like to present. Thanks! -- SY, Jen Linkova aka Furry
[ipv6-wg] RIPE80 IPv6 WG Session
Dear IPv6 Enthusiasts, The agenda for IPv6 WG at RIPE80 has been published: https://ripe80.ripe.net/programme/meeting-plan/ipv6-wg/ The instructions on how to attend the RIPE80 sessions could be found at https://ripe80.ripe.net/attend/how-to-participate/ See you there! -- SY, Jen Linkova aka Furry on behalf of IPv6 WG Chairs.
Re: [ipv6-wg] RIPE80 Call for Presentations
On Fri, Apr 24, 2020 at 9:37 PM Jens Link wrote: > I would like to see a presentation explaining what is so hard about > deploying IPv6 and what the technical difficulties are. Any volunteers? :) >If I remember > correctly in her talk at RIPE79 Veronika asked the audience who has > deployed IPv6 an only 1/4 (or 1/3) raised their hands. I'd not assume that IPv6 is not getting deployed (only) because it's hard or because of the technical difficulties. Maybe you are more lucky but I personally have a lot of things on my 'would be nice to get done' list - and none of them are hard to do. It's just they keep getting postponed because if other things which are either more urgent or more important. I'd not be surprised if IPv6 deployments suffer from the same issue quite often. -- SY, Jen Linkova aka Furry
[ipv6-wg] RIPE80 Call for Presentations
Dear IPv6 Enthusiasts, As you might have noticed, RIPE80 is going to be a virtual meeting. So IPv6 WG is going to meet on Thu, May 14th, 13:00 - 13:45 CEST (Don't forget to convert to your local timezone). We are looking for talks. COVID-19 does not seem to be a reason good enough to slow down IPv6 deployments. I suspect it might be a reason for accelerate them, actually. So stories about 'IPv6 in the Time of Cholera' (or any other talks about IPv6) are appreciated. Please send your suggestions (the title, short summary, how much time you need) to ipv6-wg-ch...@ripe.net. Thanks, -- SY, Jen Linkova aka Furry on behalf of IPv6 WG Chairs.
Re: [ipv6-wg] Have we failed as IPv6 Working Group?
On Thu, Oct 10, 2019 at 6:35 PM Carlos Friaças wrote: > > ...writing this email from IPv6-only WiFi... > > Just out of plain curiosity: home environment, corporate environment, or > something else (i.e. 3rd party-managed, like an airport, coffee-shop)? Corporate. -- SY, Jen Linkova aka Furry
Re: [ipv6-wg] Have we failed as IPv6 Working Group?
On Thu, Oct 10, 2019 at 12:06 PM Job Snijders wrote: > So... one of the ideas to be explored is that there is a only a > *single* SSID, but through WPA-802.1X let the username decide what > 'profile' you want. [skip] > There ALREADY is an IPv6-only+NAT64 Wifi SSID. Use it if you want to. If > there aren't enough users on it, go back to the drawing board and > explore why that is. We do know why. The profile approach you suggested would work just *slightly* better than two SSIDs. Users do not care. They connect to the SSID their device remembered and if there are multiple 'known' SSIDs nobody would pay attention to which SSID their device is connected to. Imagine a WiFi network with a few thousands of users. Step 1. Opt-in. You ask them to 'try IPv6-only' SSID - you must be *very* lucky if you get more than 3-5% of users moving. Not because smth does not work for them but because they are lazy. Some of those who moved will be going back and forth between SSIDs w/o even knowing it - here the 802.1x profile might help. Step 2: Opt-out. You make the 'primary' SSID Ipv6-only and advise those who are seeing issues to use another SSID. In that case I'd expect to see between 70-85% of users stay on Ipv6-only (the number does depend on mobile/laptop ratio on the network). For exactly the same reason only 5% moves if you do opt-in: users are lazy and do not care which SSID they connect to if it works. ...writing this email from IPv6-only WiFi... > I maintain, let's first move this mailing list to an IPv6 only > environment, if that is a success, perhaps we can reconsider. I might be missing smth here: what does SMTP over IPv6 to do with the ability of running an IPv6-only meeting WiFi network? >If the > argument is "but then the rest of the world can't talk to us"... > exactly. Oh then please clarify what exactly do you mean by 'moving the mailing list to Ipv6-only environment'. Running the mail server in an IPv6-only DC which has SIIT? *That* would work. Removing all Ipv4 MXes/A? No it would not and the proper analogy would be 'making the RIPE WiFi Ipv6-only w/o providing NAT64'. -- SY, Jen Linkova aka Furry
Re: [ipv6-wg] Have we failed as IPv6 Working Group?
Dear WG, I apologise for coming late to the party, a long weekend to blame.. On Sun, Oct 6, 2019 at 10:53 AM Michel Py wrote: > > If you want a war that is your choice, but please go and fight it somewhere > > else. RIPE > > mailing lists are a place to be constructive and, as Job said, excellent to > > each other. > > Read the rest of my posts. I did not start the war. I did not start this > thread. > There are two ways to lose a war : lack of funds, and lack of courage. I have > both. > > The war is global. Who do you think you are to tell me to take it somewhere > else ? > The chair of a mighty WG that has managed, in 20 years, to capture a whole > 2.5% of the Internet traffic right in your own backyard at AMS-IX ? > > Kick me out of the mailing list, if you have the power to do so. [with my co-chair hat on] Michel, I understand that you might be upset with the current state of affairs. However I believe the whole discussion would be much more productive we we refrain from personal and/or provocative remarks. Please be respectful to the WG participants, it would be highly appreciated. Thank you. -- SY, Jen Linkova aka Furry
Re: [ipv6-wg] Disband IPv6 WG
Disclaimer: this is a personal opinion, all hats off. On Sat, Oct 5, 2019 at 12:52 PM Michel Py wrote: > > I'm less excited to see that some people have started giving up > > hope and telling the rest of use we shall give up to.. > > You are fighting for your survival. I'm not sure it's about survival at all. I could definitely survive w/o IPv6 (or without any form of IP) but it's much more fun with it. I'm not even sure it's a fight even. Fight sounds too romantic or too dramatic. >Although I agree with the most recent analysis that IPv6 will not become an >orphan, you have to understand that the IPv4 ecosystem will survive no matter >what you do, Well, I've seen DECNET and Appletalks "ecosystems" in the wild long after most of the world forgot those words. Complete IPv4 extinction has never been my goal, I do not really care if some isolated networks are going to run it. >and that a war will not be in your favor. I do not think there is a war. People do what they need to do and sometimes they talk about what they have experienced, just in case others might learn smth new. > I'm not trying to run your WG. All that I am saying is that the IPv6 zealots > have been a total pain in my backside, and that the FUD they have been > spreading for the last 20 years has come out of style. > > IPv4 will survive forever. There will be a long tail indeed. Then the economics would make dual-stack suboptimal, ex. for the very special cases almost nobody cares about. What you might want to keep in mind is that different networks are in different situation re: IPv6. Some of them badly need it. Some of them got rid of Ipv4. Some of them will need it sooner or later. Some could probably survive forever using a single Ipv4 address. >I can not say the same of IPv6. You have to change your tune if you want to >survive. I appreciate people care about our survival. I even appreciate free advices ;) > > Convince everyone that IPv6 is good and IPv4 shall be turned off? > > This is what you have to stop. First of all please note it was listed as a question. An option. Not necessary the best one. >You work for Google. In case you have not noticed there is no reference to my employer anywhere, so I'd suggest we do not talk about whom I work for. It does not really matter. >Do you want to bet your career that Google is going to switch to IPv6 only ? I'm afraid to answer your question I need to go through some legal approval process. > Think carefully. Think about your career. I personally know the big shots at > big vendor who bet their careers on IPv6 and have become irrelevant. As I've said before, I'm deeply touched that someone in the Internet cares about my career ;) > You are too young to be a politician who turns their coat in the wind. Lol, I'll take this a compliment, thank you sir! > I say again : are you willing to bet your career on IPv6 ? I have done it. No regrets so far. -- SY, Jen Linkova aka Furry
Re: [ipv6-wg] Disband IPv6 WG
On Thu, Oct 3, 2019 at 9:12 PM Joao Luis Silva Damas wrote: > Did you also look at the From?, because that’s not the one I expected if I > instinctively expanded the name to that of someone I know, like the wg > co-chair or so. YeahJens, maybe before we start discussing the renaming the group we shall first decide who of us two needs to change the name? ;) People are getting confused... -- SY, Jen Linkova aka Furry
[ipv6-wg] [official] What Shall This WG Do
Hello, dear IPv[0-9] enthusiasts, supporters and zealots, As a co-chair I'm excited to see some discussion happening here, especially after the list has been quiet for a while. I'm less excited to see that some people have started giving up hope and telling the rest of use we shall give up to.. By a lucky coincidence we have 10 mins open-mic slot during IPv6 WG session in Rotterdam to discuss what the WG is doing and what we, as a community, want it to do (however after reading all those threads I'm afraid 10 mins might not be enough). What I'd like to ask you meantime is to think what the priorities and goals are. Get IPv6 adoption to 100%? (Is it realistic? Shall we target to 100%?) Convince everyone that IPv6 is good and IPv4 shall be turned off? Provide a venue for those who are interested to discuss the topic and share the experience (including negative one? Produce documents (or recommendations?) Educate people? What should be considered as success, what is the failure and what is just a roadblock? The current WG charter is available on https://www.ripe.net/participate/ripe/wg/ipv6 Please read it and let's discuss if anything should be changed there. -- SY, Jen Linkova aka Furry
Re: [ipv6-wg] Disband IPv6 WG
On Fri, Oct 4, 2019 at 4:04 AM Enno Rey wrote: > I support the proposal. > Once a protocol has reached mainstream deployment (as IPv6 has) a dedicated > WG might no longer be needed. I mean, there's no IPv4 WG either, right? Actually it's exactly what I said after I became a co-chair. Our ultimate goal should be to get rid of this group. Let' get IPv6 deployed and go home. Or to the new adventure. As you've said, we do not have IPv4 WG. Unfortunately we are not there yet. -- SY, Jen Linkova aka Furry
Re: [ipv6-wg] Disband IPv6 WG
On Thu, Oct 3, 2019 at 8:34 PM Jens Link wrote: > after now almost 12 years using, working and teaching[1] > IPv6 I've come to the conclusion that IPv6 is a mistake and will > not work. > > Therefore the RIPE IPv6 WG should be disbanded I suspect that the fact that one member has lost his faith in technology might not be a sufficient reason to close the working group... >and replaced > with a new WG that MUST investigate all possible solutions to > artificially prolong the live of IPv4 till the day a new successor > for IPv4 is created and implemented! AFAIR you need to have a BoF first before you can get a new working group ;-P https://www.ripe.net/participate/ripe/bof -- SY, Jen Linkova aka Furry
Re: [ipv6-wg] Have we failed as IPv6 Working Group?
Hi Wolfgang, On Fri, Oct 4, 2019 at 5:41 AM Wolfgang Zenker wrote: > ... the default network at RIPE Meetings is the dual-stack network, with > the IPv6-only (NAT64) network as a barely used extra which is "supported > on a best effort basis". With the effect that almost no-one except a few > "ipv6 zealots" uses it. This tells me that a significant part of the > RIPE community does not only consider this setup "not production ready" > but expects an amount of breakage so huge that it's not acceptable to > try it out and see what would actually break (while still offering a > dual-stack network as a fallback, of course). I'm not sure I can follow the logic here. What you are saying about 'do not consider production ready' would have been true if users made a decision which SSID to connect every time (and that decision took into account the protocol version). But it's clearly not the case. First time attendees connect to whatever SSID is specified in the booklet and/or has the most intuitive name. Returning attendees let their laptops/phones connect to SSID their devices remember. There is an SSID which has been there for years, which is printed on the booklets etc and it's name matches the meeting name. And there are other SSIDs - which are not listed in the booklet, their names are longer (which for MacOS at least might mean that they are shown *below* the main one in the list) etc. I'm sure that even if all of them were dual-stack, the main one would have attracted the vast majority of the userbase. > ... the results of the RIPE NCC survey published today lists the > scarcity of IPv4 addresses as one of the largest challenges facing the > participants in the survey. At the same time, about one quarter of > participants has no plans for deploying IPv6, with the most common > reason given as "there is no business requirement for IPv6". The survey says: "Over half of respondents indicated that they will need more IPv4 address space in the short term." I read it as '~50% of respondents do not need IPv4 in the short term". And only 1/4 do not see the business requirements for IPv6". Twice less that I'd have expected then.. Another quote: "A further 44% of respondents who indicate they will not need more IPv4 stated that their organisation has/will have deployed IPv6. " I'd not call it a failure. >This tells me that a significant part of the RIPE community does not view a > migration to IPv6 as a useful way to deal with the shortage of available > IPv4 address space. Yet. > I maybe wouldn't call the IPv6 WG "failed", but it clearly still has a > long way to go until we can claim "mission accomplished". I do not think anyone promised it's going to be easy ;) On a more serious note, two things: 1) I quickly checked the 2013 survey. It does not even mention IPv6. Are you still calling it 'no progress' and 'failure'? ;) 2) By lucky coincidence we have a slot in Rotterdam to discuss the working group strategy and future. Let's talk about it. -- SY, Jen Linkova aka Furry
Re: [ipv6-wg] Disband IPv6 WG
On Fri, Oct 4, 2019 at 10:45 PM Blake wrote: > As the OP's goal seems to be XKCD standards compliance(1), perhaps it's time > to revive IPv10? Well, if it's what you want to do - this list is the wrong place. https://www.ietf.org/about/participate/get-started/ is what you probably need.. > https://tools.ietf.org/html/draft-omar-ipv10-11 > > After all, it took Edison two decades to admit DC power distribution couldn't > work, & NYC only had to wait a century more until they could decommission > their > commercial DC electrical power distribution network... > ( https://en.wikipedia.org/wiki/War_of_the_currents ) I find this example irrelevant as I've seen IPv6-only networks. Oh wait, I've deployed them... -- SY, Jen Linkova aka Furry
[ipv6-wg] IPv6 WG agenda
Hello, The agenda for IPv6 WG session at RIPE79 has been published: https://ripe79.ripe.net/programme/meeting-plan/ipv6-wg/ See you all in Rotterdam! -- SY, Jen Linkova aka Furry on behalf of IPv6 WG chairs.
[ipv6-wg] ipv6 francais: If you can read French...
Very good document about IPv6 adoption in France (thanks Gordon for sharing!): https://www.arcep.fr/cartes-et-donnees/nos-publications-chiffrees/transition-ipv6/barometre-annuel-de-la-transition-vers-ipv6-en-france.html https://www.arcep.fr/fileadmin/reprise/observatoire/ipv6/Arcep_Barometre_2018_de_la_transition_vers_IPv6.pdf -- SY, Jen Linkova aka Furry
[ipv6-wg] IPv6 WG Agenda (RIPE76)
Hello, The draft agenda for Ipv6 WG sessions at RIPE76 has been published: https://ripe76.ripe.net/programme/meeting-plan/ipv6-wg/ -- SY, Jen Linkova aka Furry on behalf of IPv6 WG chairs.
[ipv6-wg] RIPE75 IPv6 WG meeting minutes
Hello, Just in time for RIPE76...;) Meeting minutes from RIPE75 IPv6 WG sessions are posted at RIPE website: https://www.ripe.net/participate/ripe/wg/ipv6/minutes/ipv6-working-group-minutes-ripe-75 If you said anything at the mic during those sessions, please review and let us know if any correction is required! Thanks! -- SY, Jen Linkova aka Furry
[ipv6-wg] Chair election
Hello, Wow, it's been 3.5 years already since I joined IPv6 WG chairs club ;) As per our current policy [1] it's time for me to step down. Fortunately for me, that policy does allow me to stand for re-election, so I'd love to serve another term as IPv6 WG co-chair if the group believes it's a good idea ;) See you all in Marseilles! [1] https://www.ripe.net/participate/ripe/wg/ipv6/ipv6-wg-chair-selection-process -- SY, Jen Linkova aka Furry
Re: [ipv6-wg] Unique /64 per host
And another related one, describing how routers can indicate in RAs that the given /64 is for one host only: https://tools.ietf.org/html/draft-pioxfolks-6man-pio-exclusive-bit-02 On Thu, Oct 26, 2017 at 12:18 AM, JORDI PALET MARTINEZ wrote: > This is the draft we mention in the WG meeting: > > https://datatracker.ietf.org/doc/draft-ietf-v6ops-unique-ipv6-prefix-per-host/ > > Regards, > Jordi > > > > > ** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company > > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the exclusive use of the > individual(s) named above and further non-explicilty authorized disclosure, > copying, distribution or use of the contents of this information, even if > partially, including attached files, is strictly prohibited and will be > considered a criminal offense. If you are not the intended recipient be aware > that any disclosure, copying, distribution or use of the contents of this > information, even if partially, including attached files, is strictly > prohibited, will be considered a criminal offense, so you must reply to the > original sender to inform about this communication and delete it. > > > > -- SY, Jen Linkova aka Furry
Re: [ipv6-wg] Captive portal over IPv6
On Tue, Oct 24, 2017 at 9:26 PM, Shahin Gharghi wrote: > I have a public WiFi service which connects people to internet via hotspot > (captive portal). I want to assign IPv6 addresses to users in dual-stack, > but my captive portal doesn't support. Do you know any captive portal that > supports IPv6? Both hardware and software models works for me. I was under impression that Aruba supports IPv6 but I'm not 100% sure... -- SY, Jen Linkova aka Furry
[ipv6-wg] RIPE74 meeting minutes
I've just realized (as I do every 6 months) that I should have sent a link for the meeting minutes from the previous meeting... Here we are: https://www.ripe.net/participate/ripe/wg/ipv6/minutes/ipv6-working-group-minutes-ripe-74 Please review and let us know if anything should be changed. Thanks! -- SY, Jen Linkova aka Furry on behalf of IPV6 WG chairs
[ipv6-wg] IPv6 WG Agenda for RIPE75
Hello, The agenda for the IPv6 WG session has been finalized and should be published soon. This time we have just one slot: A. Administrative matters [5 min] B. Geoff Huston, "Surviving IPv6 Fragmentation" [35 min] C. Wolfgang Zenker, "Webhosting on IPv6-only virtual machines - operational observations" [15 min] D. Benedikt Stockebrand, Wilhelm Boeddinghaus "IPv6 in Enterprise Network: Advanced Topics" [45 min] E. Lightning Talks [30 mins] F. IPv6 WG Chair Re-Election [10 mins] -- SY, Jen Linkova aka Furry on behalf of IPv6 WG chairs.
Re: [ipv6-wg] IMPORTANT: RIPE75 is SPECIAL (call for presentations)
On Tue, Jul 4, 2017 at 8:04 AM, Fernando Gont wrote: [WG chairs hat OFF] > Just out of curiosity: Why should a remote presenter provide a passport? Whatever I say will be just a guess, how can I speak for the UAE government? My guess would be that they want to make sure that remote presenters are not using pseudonyms. What if I submit a remote presentation as Fernando Gont and start advocating inserting Ipv6 extension headers on the fly, for example? ;))) > That seems to me like a weird requirement to me, and possibly even hard > to enforce (unless there's someone watching a video stream and checking > if they have a copy of the passport for that person?). And, if the > person is not traveling anyway, he/she might not even have a passport in > the first place. I'd expect that some other form of government-issued ID would do - but again, I'm speculating. > (yes, I understand you're just the messenger :-) ) Thanks, highly appreciated ;) -- SY, Jen Linkova aka Furry
[ipv6-wg] RIPE73 meeting minutes
Hello, I know I should have sent this email long time ago but better late than never... Anyway, the meeting minutes for RIPE73 IPv6 WG sessions could be found at https://www.ripe.net/participate/ripe/wg/ipv6/minutes/minutes-from-the-ipv6-working-group-at-ripe-73 Please review them (especially if you said anything at the mic), and let us know if there are any errors/omissions. Again, sorry for being late with sending this email. I'd also like to thank RIPE NCC for providing the meeting minutes! -- SY, Jen Linkova aka Furry on behalf of IPv6 WG chairs.
[ipv6-wg] RIPE74 - call for presentations
Hi there ;) If you'd like to present at IPv6 WG sessions at RIPE74 or have some ideas/suggestions for the agenda - please contact ipv6-wg-cha...@ripe.net. Thanks and see you in Budapest! --- On behalf of IPv6 WG Chairs, Jen Linkova aka Furry
Re: [ipv6-wg] Happy Eyeballs bias
On Wed, Oct 26, 2016 at 5:27 PM, Philip Homburg wrote: > I wonder, if a host has a global IPv6 address that is not derived from any > kind of transition technology or tunnel, and setting up a TCP connection is > either slow or fails, then what percentage is due to an issue close to the > host and what percentage close to the target. > > I.e., if IPv6 is broken is there any reason to believe it is often enough > due to ISP provided services that is would be worth reporting it in a > roudabout way. I'd say that it is much more likely to be broken close to clients, at least for Alexa web sites.. -- SY, Jen Linkova aka Furry
Re: [ipv6-wg] Happy Eyeballs bias
On Wed, Oct 26, 2016 at 3:54 PM, Sander Steffann wrote: > So, how about we go the other way. We want IPv6 to be taken more seriously. > What about if we change the algorithm the other way over time: give IPv6 more > and more of a head start. That way IPv6 stability and performance become more > important over time, without causing brokenness. Something like: > > HE head start = 300 + (months after 2017-01-01) * 30 > > That would provide some incentive to make sure that IPv6 is properly deployed > and managed. Well, if you keep increasing the timeout you'll eventually make the failover time worse than it would have been w/o HE. Basically the timeout should be long enough to keep Ipv6 preferred in most of 'non-broken' cases but short enough so if IPv6 is broken, users do not notice the failover. -- SY, Jen Linkova aka Furry
Re: [ipv6-wg] Panel Discussion on IPv6 in enterprise networks (was : Re: ipv6-wg Digest, Vol 55, Issue 2)
On Sun, Oct 2, 2016 at 2:00 AM, Radu-Adrian FEURDEAN wrote: >> > 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! :) > > Any news ? It was supposed to be pushed to the next RIPE meeting. > I would be also interested in participating. Unfortunately we could not organize it this time (due to some scheduling conflicts) but we keep it in mind for the next meeting... Sorry.. -- SY, Jen Linkova aka Furry
Re: [ipv6-wg] Chair selection: call for candidates
Anna, Let me thank you for all your work as a WG co-chair! On Thu, Sep 15, 2016 at 2:51 PM, Anna Wilson wrote: >> We therefore call for candidates for the post of IPv6 working group >> chair. If you would like to stand for selection, please announce so to >> the mailing list. The closing date for candidates is 23:59 UTC on Friday >> 21st October 2016. (The Friday before the RIPE73 meeting.) > > While the procedure allows a chair to stand for re-selection at the end > of their term, I do not plan to do so. Thank you all for the opportunity > to help, and I'm looking forward to participating in future! > > Best regards, > Anna > > -- > Anna Wilson, Service Desk Manager web: www.heanet.ie > HEAnet Ltd, 5 George's Dock, IFSC, Dublin 1 tel: +353-1-660-9040 > Registered in Ireland, no 275301fax: +353-1-660-3666 > -- SY, Jen Linkova aka Furry
[ipv6-wg] RIPE73, IPv6 WG: Call for presentations
Hi there ;) Time flies, RIPE73 is less than two months away. If you'd like to present at IPv6 WG sessions in Madrid, or just have a suggestion for the agenda - please contact ipv6-wg-cha...@ripe.net. (If you could provide a short summary of your talk and how much time you need- it would help a lot to build an agenda and would be highly appreciated ;)) Thanks and see you in Madrid! --- On behalf of IPv6 WG Chairs, Jen Linkova aka Furry
Re: [ipv6-wg] [members-discuss] manufacturers of routers and IPV6
On Sat, Jul 23, 2016 at 11:18 AM, Куприянов Роман wrote: > Dear colleagues. > > Is there any possibility of the community affect the router manufacturer to > implement the required functionality for the implementation of IPV6? Isn't it smth we are doing all the time? >From my experience vendors seldom implement features "just for fun" - usually there is a customer (or customers) asking for it. So yes, please keep telling your vendors "I need this and that IPv6 features in your equipment or I'm not buying it". P.S. Do you keep any specific vendor/required functionality in mind? > > -- > Best regards, > Kupriyanov Roman (ru.enigma) -- SY, Jen Linkova aka Furry
Re: [ipv6-wg] v4 versus v6 -- who connects faster?
On Mon, May 23, 2016 at 2:29 PM, Jen Linkova wrote: > On Mon, May 23, 2016 at 2:15 PM, Nico CARTRON wrote: >>> [a] http://goo.gl/hbzbwD > >> Out of curiosity, I tried accessing it from the NAT64 Wifi network at >> RIPE72, >> and http://dragon.eecs.jacobs-university.de:5000 seems not to work for some >> reason. >> Thoughts? > > furry@Wintermute:~>dig dragon.eecs.jacobs-university.de +short > 2001:638:709:3000::3a > furry@Wintermute:~>telnet -6 dragon.eecs.jacobs-university.de 5000 > Trying 2001:638:709:3000::3a... > telnet: connect to address 2001:638:709:3000::3a: Connection refused > telnet: Unable to connect to remote host > > That host does have IPv6 address in DNS (so no NAT64 is involved) but > nothing is listening on tcp/5000 on that IPv6 address. ...or there is a firewall on the path blocking connections and sending RST back... -- SY, Jen Linkova aka Furry
Re: [ipv6-wg] v4 versus v6 -- who connects faster?
On Mon, May 23, 2016 at 2:15 PM, Nico CARTRON wrote: > Here [a] is a toy v6 service I came up with during the RIPE > Atlas hackathon over this weekend. Thought I share this along: > > [a] http://goo.gl/hbzbwD > > You enter a dual-stacked website (ALEXA top 10K) and it shows > you the difference in TCP connect times over v4 and v6 as seen > by all dual-stacked RIPE Atlas probes (~1.3K probes). You can > also filter the visualisation from a specific origin-AS. This > additional filter can be useful to view performance towards a > website from a specific origin-AS (say DTAG). > > Disclaimer: This is an outcome of a 1.5d long hackathon project. > As such, the codebase is possibly inundated with bugs. Please > don’t see it as a production service :-) > > Nice job, congratulations. > > Out of curiosity, I tried accessing it from the NAT64 Wifi network at > RIPE72, > and http://dragon.eecs.jacobs-university.de:5000 seems not to work for some > reason. > Thoughts? 1) Does it work from the dual-stacked network? I'm seeing significant packet loss on wireless right now, on both dual-stacked and v6-only network, so it might the reason 2) how exactly does it fail? DNS resolution/connection timeout? -- SY, Jen Linkova aka Furry
Re: [ipv6-wg] v4 versus v6 -- who connects faster?
On Mon, May 23, 2016 at 2:15 PM, Nico CARTRON wrote: >> [a] http://goo.gl/hbzbwD > Out of curiosity, I tried accessing it from the NAT64 Wifi network at > RIPE72, > and http://dragon.eecs.jacobs-university.de:5000 seems not to work for some > reason. > Thoughts? furry@Wintermute:~>dig dragon.eecs.jacobs-university.de +short 2001:638:709:3000::3a furry@Wintermute:~>telnet -6 dragon.eecs.jacobs-university.de 5000 Trying 2001:638:709:3000::3a... telnet: connect to address 2001:638:709:3000::3a: Connection refused telnet: Unable to connect to remote host That host does have IPv6 address in DNS (so no NAT64 is involved) but nothing is listening on tcp/5000 on that IPv6 address. -- SY, Jen Linkova aka Furry
Re: [ipv6-wg] IPv6 residential service: What prefix, static, dynamic, extra cost ?
On Thu, May 19, 2016 at 10:19 AM, Mikael Abrahamsson wrote: >>> PD: In my opinion it should be /48 by default, static and opt-in to >>> dynamic, no extra charge on top of the Internet service price, but I know >>> many ISPs will not agree :-( Here just trying to collect the info in a >>> single place. >> >> [Disclaimer] I've not been involved in ISP business for a while] but... >> why /48? /56 would give 256 subnets. ought to be enough for anybody >> IMHO (unless your definition of 'residential customer' is quite >> different from mine...) > > > My opinion is that anything between /56 and /48 is fine. As far as I know, > current RIPE policy gives the ISP the option to without motivation, ask for > enough IPv6 addresses to offer each customer a /48 and I'd like to keep it > that way. > > But you're correct, it seems most deployments are going for /56 for no more > reason than that it "should work for everybody". Of course /48 works as well > as it's a superset of /56. I'm not going to give anyone who gives everybody > a /48 a hard time and I don't want RIPE to do it either. Oh, don't get me wrong - I'm not going to give anyone a hard time for assigning /48 for households. I was asking only because I've spent some time recently on various v6 address plans and by default I'm assigning /56, so I'm just wondering if I'm missing anything and there is any good reason for assigning /48 (the only reason I can think of is 'one day that site might want to be multihomed...'). -- SY, Jen Linkova aka Furry
Re: [ipv6-wg] IPv6 residential service: What prefix, static, dynamic, extra cost ?
On Wed, May 18, 2016 at 8:45 PM, JORDI PALET MARTINEZ wrote: > PD: In my opinion it should be /48 by default, static and opt-in to dynamic, > no extra charge on top of the Internet service price, but I know many ISPs > will not agree :-( Here just trying to collect the info in a single place. [Disclaimer] I've not been involved in ISP business for a while] but... why /48? /56 would give 256 subnets. ought to be enough for anybody IMHO (unless your definition of 'residential customer' is quite different from mine...) -- SY, Jen Linkova aka Furry
Re: [ipv6-wg] ipv6-wg Digest, Vol 55, Issue 2
On Thu, May 5, 2016 at 1:11 PM, Jens Link wrote: > 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. Your statement is true - but in the ideal world only... -- SY, Jen Linkova aka Furry
Re: [ipv6-wg] what is v6-only?
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. 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). So in general I'd expect the term "IPv6-only" to cover both a) and b) as b) is just a) with an additional service on top. -- SY, Jen Linkova aka Furry
[ipv6-wg] IPv6 WG Agenda
Hi IPv6-Enthusiasts ;) I'm sure most of you have noticed that already, but the agenda for IPv6 WG sessions @ RIPE72 has been published: https://ripe72.ripe.net/programme/meeting-plan/ipv6-wg/ See you in Copenhagen soon! -- SY, Jen Linkova aka Furry on behalf of IPv6 WG Chairs
Re: [ipv6-wg] ipv6-wg Digest, Vol 55, Issue 2
On Tue, May 3, 2016 at 12:37 AM, Benedikt Stockebrand wrote: >>> 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(?) Sounds like a plan ;) -- SY, Jen Linkova aka Furry
[ipv6-wg] RIPE72 IPv6 WG: call for presentations
Dear IPv6 Enthusiasts ;) I know that 23 of May 2016 when RIPE72 will start looks so away but we (IPv6 WG Chairs) like to plan ahead! If you would like to present at IPv6 WG session or just have any suggestions on the agenda (what we should or should not be talking about) - please email ipv6-wg-cha...@ripe.net >From presenters we need the following information: - a tentative title of your talk; - short summary - how much time you need (I'd recommend allowing 5 mins for questions). For the last few meetings we filled all the agenda slots quite earlier and unfortunately had to reject a number of interesting talks because they were submitted too late. So don't be shy! If you *might* be able to present but not sure yet - also let us know. -- SY, Jen Linkova aka Furry on behalf of IPv6 WG Chairs.
Re: [ipv6-wg] ripemtg-nat64 network at RIPE71: complain here ;)
On Tue, Nov 17, 2015 at 2:22 PM, Job Snijders wrote: >> Please use ripemtg-nat64 SSID. Please let us know if smth goes wrong. > > I can't get it to work on my "Blackberry Classic (SQC100-1)" with BBOS > 10.3.2.2474. Unsure what the current state of IPv6 support on BBOS is, > it appears the device has an IPv6 link-local address on the WiFi > interface, but it doesn't have a global address. I don't know why, maybe > it doesnt speak the proper bootstrap protocol. Does it get IPv6 address while connecting to the dual-stack SSID? If yes, does it use it (http://ipv6.test-ipv6.com/)? -- SY, Jen Linkova aka Furry
Re: [ipv6-wg] ripemtg-nat64 network at RIPE71: complain here ;)
On Mon, Nov 16, 2015 at 3:22 PM, Wilfried Woeber wrote: > I may be looking at something that isn't expected to work in this set-up at > all, but still: > > traceroute to my workstation back home in "default" command-line does not > work, it comes > back with "network is unreachable". Adding -6 flag to force using the > DNS response > makes it work. According to the man page it should select the version > automatically. > > Requesting TCP mode fails completely to come back with answers, even when > forcing -6 So does TCP mode work for Ipv6 address on the dual-stack network? -- SY, Jen Linkova aka Furry
Re: [ipv6-wg] ripemtg-nat64 network at RIPE71: complain here ;)
On Mon, Nov 16, 2015 at 12:58 PM, Leslie wrote: > Colloquy still breaks on 64 - http://colloquy.info/project/ticket/2645 :( I've commented on that ticket as well. BTW Adium seems to work just fine. > > On Mon, Nov 16, 2015 at 1:55 PM, Jen Linkova wrote: >> Hi guys, >> >> As you might have noticed there is a NAT64 SSID. >> This thread is for complains about that network. >> >> Please use ripemtg-nat64 SSID. Please let us know if smth goes wrong. >> >> if you have network issues while using that SSID and switching to >> dual-stack one fixes the problem - please reply to this thread (indeed >> you can create a new one, I was just thinking that keeping everything >> in one thread might make our life easier but I might be wrong...). >> >> >> -- >> SY, Jen Linkova aka Furry >> -- SY, Jen Linkova aka Furry
Re: [ipv6-wg] ripemtg-nat64 network at RIPE71: complain here ;)
On Mon, Nov 16, 2015 at 1:45 PM, Timo Hilbrink wrote: > On 16/11/2015 12:55, Jen Linkova wrote: >> Hi guys, >> >> As you might have noticed there is a NAT64 SSID. >> This thread is for complains about that network. >> >> Please use ripemtg-nat64 SSID. Please let us know if smth goes wrong. > > My phone can't connect to this SSID, HTC One S, Android 4.1.1 > > It hangs on 'Authenticating', gives up after a while, and marks the SSID > with 'Avoided poor internet connection' :) It is known issue fixed in Android 5-smth. What's happening is the device is trying to get v4 address. What you could do it to manually configure v4 address (any address, 192.0.2.2 would do) and, indeed, DNS64 as DNS server (which seems to be 2001:67c:64:47::c100:1fee). -- SY, Jen Linkova aka Furry
Re: [ipv6-wg] ripemtg-nat64 network at RIPE71: complain here ;)
>> As you might have noticed there is a NAT64 SSID. >> This thread is for complains about that network. >> >> Please use ripemtg-nat64 SSID. Please let us know if smth goes wrong. >> >> if you have network issues while using that SSID and switching to >> dual-stack one fixes the problem - please reply to this thread (indeed >> you can create a new one, I was just thinking that keeping everything >> in one thread might make our life easier but I might be wrong...). > > Thanks Jen, > > May I suggest people include device make and model and software versions > involved when complaining about application or OS behaviour? > > Makes it easier to run statistics and assessing how big the impact on the > total user population would be, if one would deploy this technique in > production environment. Very good point indeed, thanks Marco! It would be great if complains would include troubleshooting info whenever possible - as much as reporting user is willing/able to collect and share. -- SY, Jen Linkova aka Furry
[ipv6-wg] ripemtg-nat64 network at RIPE71: complain here ;)
Hi guys, As you might have noticed there is a NAT64 SSID. This thread is for complains about that network. Please use ripemtg-nat64 SSID. Please let us know if smth goes wrong. if you have network issues while using that SSID and switching to dual-stack one fixes the problem - please reply to this thread (indeed you can create a new one, I was just thinking that keeping everything in one thread might make our life easier but I might be wrong...). -- SY, Jen Linkova aka Furry
Re: [ipv6-wg] IPv6-only network during RIPE 71
On Sat, Nov 7, 2015 at 2:29 PM, Benedikt Stockebrand wrote: > 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? Oops, sorry, as some discussion on this topic did happen off-list, let me explain: I'll submit a lighting talk for Monday plenary to tell people about v6-only SSID and to invite them to join our Wed session to discuss the future plans. -- SY, Jen Linkova aka Furry
Re: [ipv6-wg] IPv6-only network during RIPE 71
On Tue, Nov 3, 2015 at 2:19 PM, Philip Homburg wrote: >>> (Can't wait for a request for Atlas to support NAT64, that's going to be >>> interesting) >> >>Request! > > I'll pass the request onto MCB on your behalf noting that a quick measurement > shows that no probe is actually behind a DNS64 resolver. So it may > not get a very high priority. Oops, sorry, I need to turn on my router and my probe connected to it as soon as I'm back home ;) So you could see at least one such probe ;) -- SY, Jen Linkova aka Furry
Re: [ipv6-wg] RIPE Atlas and NAT64 (Was: IPv6-only network during RIPE 71)
On Tue, Nov 3, 2015 at 3:18 PM, Gert Doering wrote: >> RIPE Atlas probe is a host. It should not care much if it's traffic is >> going via NAT64 box or not. > > Actually detecting NAT64 and flagging as such, and being able to run > tests on a group of NAT64-hidden probes might add value... I think there is a dirty hack to do it now: run a measurements from v6-enabled probes to v4-only host, check the results for the destination address they were using. But I agree, it would be nice to get a list of probes behind NAT64 w/o wasting time and credits ;) -- SY, Jen Linkova aka Furry
Re: [ipv6-wg] IPv6-only network during RIPE 71
On Tue, Nov 3, 2015 at 11:53 AM, Philip Homburg wrote: > The network at RIPE meetings currently provides a good network experience. > The wifi works, there is IPv6 that works, and for those > living in the past (which is essentially all of us, because only > a small fraction of the internet is actually reachable over IPv6), there is > also native IPv4. > > The surprising thing to me is that there is a request to the ops team > at the meeting to provide broken IPv4 by default. > > I can understand the desire to have experimental networks at a meeting > to test what works and what doesn't work. > > But why should such a broken network be default? There are many broken > networks in the world. Wifi often doesn't work, in many places there is > no 3G GSM. Do we want to replicate that as well at a RIPE meeting? I'm not sure I understand why you are calling v6-only network 'broken one'? I've been sitting in v6-only network at RIPE meetings since that SSID was introduced. I'm in Japan now and so far I did not have to connect to dual-stack SSID - v6-only works just fine. What exactly (besides a few applications) is broken here? > (Can't wait for a request for Atlas to support NAT64, that's going to be > interesting) RIPE Atlas probe is a host. It should not care much if it's traffic is going via NAT64 box or not. -- SY, Jen Linkova aka Furry
Re: [ipv6-wg] IPv6-only network during RIPE 71
On Sat, Oct 31, 2015 at 1:24 PM, Jen Linkova wrote: > As this topic seems to be a hot one for this WG, I'm planning to > reserve some time during the WG session in Bucharest for the > 'open-mic' discussion. Correction: this discussion will happen at the end of Wed WG slot to avoid to some meeting conflicts. -- SY, Jen Linkova aka Furry
Re: [ipv6-wg] IPv6-only network during RIPE 71
Hi Marco, Thanks a lot for such detailed response. Some comments inline: On Thu, Oct 29, 2015 at 11:30 AM, Marco Hogewoning wrote: > Our primary concern is that within the resource constraints we have on staff > time and expertise, we cannot offer detailed support to end users, who are > experiencing problems. Hopefully most of support which is specific to IPv6-only network should be 'please switch to dual-stack and let us know if it helps'. > Taken into account the discussion in this working group, we do agree that > labelling the IPv6-only network as “experimental” might have unintended > consequences and leave the impression that IPv6 is not ready for deployment. > > We support the working group in their efforts to change the messaging > surrounding this initiative to make it appear less experimental and put more > confidence in IPv6 as a technology, which is ready for broad deployment. > > At the same time we are not assured that an IPv6-only environment will not > lead to any problems at the user level, which might be perceived as a problem > with the RIPE meeting network. > > We are happy to work with the community in implementing changes to the > network name and documentation and promotion efforts. Our IT staff has > confirmed that we can change the name and password without much effort and > this can be done prior to RIPE 71. I agree that we should take baby steps and do not change too many things at once. If we can get rid of 'experimental' label prior to RIPE71 it would be great. > However we must also insist that, at this stage, that there must be no > confusion with the primary dual stack network, which is supported by RIPE NCC > staff. > > On an additional note we must warn the community on the use of any relative > or subjective names such as “new” and select an alternative that provides a > functional description of the network. What about - changing SSID name to smth like 'RIPEMTG-NO-V4' or 'RIPEMTG-NAT64'? As it would be a new SSID, it minimized chances of people connecting to it accidentally, w/o understanding what they are doing. - stop using the word 'experimental' and list this new SSID among other SSIDs set up for the meeting? > We invite the community to use this upcoming RIPE meeting to collect further > feedback and develop user level documentation on any remaining problems and > any possible workarounds that could avoid such issues. > > We hope that this documentation in turn can form the basis for a discussion > with the broader RIPE community on a proposal to change configuration of the > primary network and provide confidence that such a change would not lead to > any operational problems for RIPE meeting attendees or otherwise have impact > on the stability of the RIPE NCC operated infrastructure. As this topic seems to be a hot one for this WG, I'm planning to reserve some time during the WG session in Bucharest for the 'open-mic' discussion. -- SY, Jen Linkova aka Furry
Re: [ipv6-wg] IPv6-only network during RIPE 71
+ Marco, Nick On Mon, Oct 26, 2015 at 11:02 AM, Gert Doering wrote: > On Mon, Oct 26, 2015 at 10:46:02AM +0100, Ond??ej Caletka wrote: >> I think the technology is mature enough to be provided as a regular RIPE >> NCC service during the meeting - that means regular network name and, >> most important, a password that is propagated in the same way the normal >> Wi-Fi network password is. This is especially important for the one >> third of newcomers that have had a big troubles learning the password of >> the IPV6ONLYEXP network. >> >> After RIPE 70, I proposed a "drastic" approach [1], renaming the >> dual-stack meeting network to -legacy and promote the NAT64 network as >> the default. This is the same way they do it on FOSDEM since 2014 [2]. >> But maybe we could try a slow start first, keeping the dual-stacked >> network the default and offering the NAT64 network with some suffix like >> -v6only. > > I'm with you that we should no longer market the IPv6-only as "this is an > experiment, it will not work, and is unreliable anyway, so use on your > own risk!" network. This is what Internet looks like on more and more > mobile networks already today - time to get used to it. > > OTOH, I'm not sure whether it should be default - can Android cope with > IPv6-only networks today? All new versions (5.x AFAIR) work well, I think I demonstrated it on the last meeting ;) >If yes, then go for it :-) - if not, maybe not > this year... Marco, Nick - what do you think? I definitely see a lot of interest and support in the community for moving IPv6-only network out of the experimental state. Probably moving dual-stack network to legacy this meeting might be bit extreme (we do care about people who do not care about Ipv6 yet, don't we? ;)) and we do not provide bad network experience), but what about stop calling it "experimental" and include it in the list of the standard SSIDs? -- SY, Jen Linkova aka Furry
Re: [ipv6-wg] [ipv6-wg-chair] ipv6 deployment startup
Hi Nadim, On Sat, Sep 12, 2015 at 9:59 PM, Nadim Houeiss wrote: > looking to start the deployment of ipv6 only network for a new part in my > network , i need to have info about wish solution will be the best to be > used for NAT64 techniques for new ipv6 only end users will be able to reach > ipv4 different services and web servers on the web. As far as I know most network vendors (Cisco, Juniper etc) support NAT64 on their equipment. However don't forget that you'd need DNS64 as well, so I'd suggest to check if the DNS solution you are using currently supports DNS64. >From my experience the main issue is not choosing a vendor for NAT64 but dealing with broken applications: - applications which assume than "no IPv4 address" means "no Internet connectivity" and not even trying to establish any connections if the device does not receive Ipv4 address; - applications which are using IPv4 literals; - applications which ask for "A" DNS RR only, so DNS64 does not help etc. > looking forward for your reply, BTW I'm removing ipv-wg-chairs@ (as it is just an alias which is used to reach RIPE IPv6 Working group chairs) and adding RIPE IPv6 mailing list. -- SY, Jen Linkova aka Furry
Re: [ipv6-wg] Promote the use of IRC
On Wed, Aug 12, 2015 at 2:17 PM, Daniel Baeza (Red y Sistemas TVT) wrote: > Yesterday, I've started a discussion in the member list 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. > > 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. [WG-chair hat on] What does 'administrated' mean in this case? I'd love to know what I've been volunteered for ;) Especially taking into account that WG chairs have other day jobs and are not necessary able to monitor IRC channel on regular basis. [WG-chair hat off] If people would like to have a place to informal chat nobody could prevent them. However I have a few concerns. In particular, segmentation of the information. IRC would one more communication channel to track (and it is not the best one if you would like to find out what happened while you've been on vacation, for example). We do not have so much traffic on ipv6 mailing list so I do not see a use case for offloading informal discussions to IRC channel to increase signal/noise ratio. If someone would like to have an informal chat about IPv6 @irc - there are IPv6-related channels around so I'm inclined to use Occam's razor here ;) -- SY, Jen Linkova aka Furry
[ipv6-wg] RIPE71 IPv6 WG: call for presentations
Dear IPv6 Enthusiasts, RIPE71 is just 4 months away and it's time to start thinking about IPv6 WG session agenda! If you would like to present, or just have any suggestions on what we should discuss) - please email ipv6-wg-cha...@ripe.net. If you would like to present, we need the following information: - a tentative title of your talk; - short summary - how much time you need (I'd recommend allowing 5 mins for questions). Thank you! -- SY, Jen Linkova aka Furry on behalf of IPv6 WG chairs.
Re: [ipv6-wg] [v6ops] Extension Headers / Impact on Security Devices
On Wed, Jun 17, 2015 at 3:24 AM, Brian E Carpenter
wrote:
> On 17/06/2015 07:02, Jen Linkova wrote:
>> https://tools.ietf.org/html/draft-wkumari-long-headers-03
>>
>> Comments are appreciated...
>
> In REQ-2 on HbH headers, you say:
>
>> The forwarder MUST
>> process each option as specified in Section 4.2 of [RFC2460].
>
> That aspect of RFC 2460 was fundamentally changed by RFC 7045.
Oh, very good point. Thanks for pointing this out. Looks like it does
cover our REQ2 (but requires different behavior).
So, Section 2.1 RFC7045 says about *all* EHs:
"If a forwarding node discards a packet containing a standard IPv6
extension header, it MUST be the result of a configurable policy and
not just the result of a failure to recognise such a header. "
and then, in Section 2.1 for HbH:
"The IPv6 Hop-by-Hop Options header SHOULD be processed by
intermediate forwarding nodes as described in [RFC2460]. However, it
is to be expected that high-performance routers will either ignore it
or assign packets containing it to a slow processing path. ".
I read this as 'if a router does not recognize/parse the HbH header,
it MUST not discard it unless there is an explicit policy configured.
It may just ignore it or send for "special processing" via slow path.
So it assumes that it is always safe to ignore HbH header (as if all
options in the header had highest-order two bits set to '00') while
our draft proposed quite different approach ("drop and send ICMP
back").
Ignoring HbH header seems to be reasonable and safe if we are sure
that every single existing or to be developed HbH option can be safely
ignored (or options which could be ignored must be in the very
beginning of the header...).
In the light of RFC7045 it looks to me that one possible approach for
REQ2 might be:
- if a forwarder can not parse the HbH header and there is no
explicitly configurable policy, it SHOULD
either:
-- if the forwarder can not parse any of options or if all parsed
options have highest-order two bits set to '00') - ignore the header;
-- if the forwarder was able to parse some of options and at least
one of the options has highest-order two bits set to smth except '00'
- discard the packet and send ICMPv6 message if Section 4.2 of RFC
2460 requires so (sending ICMPv6 MAY be subject to a configurable
policy)
or send it to slow path for full header processing (subject to a
configurable policy).
How does that sound?
> I'm sure other things in the long-headers draft need revising as a
> result of RFC 7045, since its whole topic is the handling of extension
> headers ("This document updates RFC 2460 to clarify how intermediate
> nodes should deal with such extension headers and with any that are
> defined in the future.")
Yes, we'll revise it, thanks for the comment.
>
> Y'all also need to take account of RFC 7112, which forbids fragmented
> header chains.
We do mention 7112 but I agree, we should explicitly mention that
header chain is limited by a packet size...Will update the doc.
--
SY, Jen Linkova aka Furry
Re: [ipv6-wg] [v6ops] Extension Headers / Impact on Security Devices
On Wed, Jun 17, 2015 at 3:33 PM, Enno Rey wrote: >> I see *large* variable length headers, in combination with complex >> parsing rules, as the problem. > > (*large* variable headers) exactly, plus fragmentation Fragmentation is not specific to IPv6, is it? And, as the fragment header itself is just 8 bytes (AFAIR, too lazy to check ;)) - I'd not classify it as *large* variable header. > and "ambiguities" wrt fragmentable vs. unfragmentable part and how headers > point to the next one once there's a cut between them due to fragmentation. > the, what we consider, "problem space" is much larger, unfortunately. Has not RFC7112 addressed this particular problem? -- SY, Jen Linkova aka Furry
Re: [ipv6-wg] [v6ops] Extension Headers / Impact on Security Devices
On Wed, Jun 17, 2015 at 2:02 PM, wrote: >> IMHO it's reasonable to assume that one might >> need different hardware for "just routing" and enhanced QoS/ACL >> services (it's a case nowadays anyway). > > You may feel it is reasonable. Not everybody agrees. If we compare > with IPv4: All modern routers I know of (including high speed boxes > with multiple 10G and 100G ports) are able to handle stateless ACLs > based on IPv4 addresses and port numbers. The boxes with multiple > 10G and 100G ports process these ACLs at line rate. I don't pay extra > for this functionality - possibly because a box *without* such > functionality would have a limited market. [skip] > I agree that the IPv4 packet may have options, making it variable > length. However the length is still limited by the IHL field, which > has a max value of 15 (60 bytes). I'm glad you mentioned 60 bytes ;) Because there are a lot of reasonably modern hardware around which copies 64 bytes on-chip. Which means if you happen such hardware in your network and your stateless ACL have 'match tcp flags' rules, you might get quite unexpected results processing packets with 60 bytes IPv4 headerSo, while it might be perfectly fine to have such cars in the core, I'd expect people not to install then at the border routers which are supposed to perform enhanced ACL services. It was my point. So we all agree that 'variable length is OK as long as our hardware can look deep enough'? And what people are complaining about is exact number? Which we do not know yet for IPv6 EHs? -- SY, Jen Linkova aka Furry
Re: [ipv6-wg] [v6ops] Extension Headers / Impact on Security Devices
t 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/ >>> >>> >> >> -- >> Enno Rey >> >> ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de >> Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 >> >> Handelsregister Mannheim: HRB 337135 >> Geschaeftsfuehrer: Enno Rey >> >> === >> Blog: www.insinuator.net || Conference: www.troopers.de >> Twitter: @Enno_Insinuator >> === >> >> ___ >> v6ops mailing list >> v6...@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > > > ___ > v6ops mailing list > v6...@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > -- SY, Jen Linkova aka Furry
Re: [ipv6-wg] [v6ops] Extension Headers / Impact on Security Devices
On Thu, Jun 11, 2015 at 6:58 PM, Enno Rey wrote:
> the problem here is the definition of "normal IP packet" as of RFC2460.
The problem here is what one might mean by "normal" (from Oxford dictionary):
1) conforming to a standard;
2) usual, typical, or expected;
> To illustrate this I just quote from today's Cisco advisory (Cisco IOS XR
> Software Crafted IPv6 Packet Denial of Service Vulnerability) on packets
> potentially crashing CRS-3 line cards:
>
> "The vulnerability is due to incorrect processing of an IPv6 packet carrying
> IPv6 extension headers that are valid but unlikely to be seen during normal
> operation. An attacker could exploit this vulnerability by sending such an
> IPv6 packet to an affected device that is configured to process IPv6 traffic.
> An exploit could allow the attacker to cause a reload of the line card,
> resulting in a DoS condition."
>
> two question come to mind here:
>
> - is a "valid but unlikely" extension header chain "normal"?
It is "normal" if you define "normal" as "conforming to a standard",
but it's not "normal" if you define "normal" as "usual/typical".
> - what ("combination of FW & IPS or whatever") would you put in front of a
> CRS?
Nothing. There is smth to put *on* CRS however - the image which
contains the fix...
I do not think we should blame a protocol for software bugs. I've seen
router crashes caused by ICMP and BGP packets. Shall we go ahead and
start discussing deprecation of the two above mentioned protocols? ;)
Especially taking into account than some people like filtering ICMP on
the edge of their networks? ;)
> my (sad) expectation is that we'll see much more of these (types of) issues
> in the future. given the current level of freedom that the RFC2460 leaves
> (see also discussion/picture in
> http://www.insinuator.net/2015/06/is-ipv6-more-secure-than-ipv4-or-less/)
> "properly parsing an IPv6 packet, let alone in wire speed" seems a pretty
> much unsolvable task to me.
(shameless plug) a group of enthusiasts have just submitted a new
version of document which discusses exactly this problem:
https://tools.ietf.org/html/draft-wkumari-long-headers-03
Comments are appreciated...
--
SY, Jen Linkova aka Furry
Re: [ipv6-wg] IPv6-only network at RIPE70
On Tue, May 12, 2015 at 2:50 PM, Jérôme Fleury wrote: > I suspect Dropbox to hardcode their IP in their application. It's not > working at all on ipv6-only. Heh, they are not hardcoding anything, they are just not consistent: 1) asking for for client.v.dropbox.com 15:10:32.233655 IP6 2001:67c:64:49:4c02:64ed:71e7:a16.62668 > nat64-ubuntu.ripemtg.ripe.net.domain: 54028+ ? client.v.dropbox.com. (38) 15:10:32.234425 IP6 2001:67c:64:49:4c02:64ed:71e7:a16.58556 > nat64-ubuntu.ripemtg.ripe.net.domain: 28552+ ? d.dropbox.com. (31) 15:10:32.270841 IP6 nat64-ubuntu.ripemtg.ripe.net.domain > 2001:67c:64:49:4c02:64ed:71e7:a16.58556: 28552 3/4/0 CNAME d.v.dropbox.com., 64:ff9b::6ca0:ace1, 64:ff9b::6ca0:acc1 (241) 15:10:32.279229 IP6 nat64-ubuntu.ripemtg.ripe.net.domain > 2001:67c:64:49:4c02:64ed:71e7:a16.62668: 54028 2/4/0 64:ff9b::6ca0:accc, 64:ff9b::6ca0:acec (230) 2) but then asking for A only: 15:10:32.643915 IP6 2001:67c:64:49:4c02:64ed:71e7:a16.51052 > nat64-ubuntu.ripemtg.ripe.net.domain: 42675+ A? d.v.dropbox.com. (33) 15:10:32.647198 IP6 nat64-ubuntu.ripemtg.ripe.net.domain > 2001:67c:64:49:4c02:64ed:71e7:a16.51052: 42675 2/4/0 A 108.160.172.193, A 108.160.172.225 (201) 15:10:32.650615 ARP, Request who-has d.v.dropbox.com tell 169.254.64.90, length 28 -- SY, Jen Linkova aka Furry
Re: [ipv6-wg] IPv6-only network at RIPE70
On Tue, May 12, 2015 at 3:00 PM, Jen Linkova wrote: > On Tue, May 12, 2015 at 2:50 PM, Jérôme Fleury wrote: >> I suspect Dropbox to hardcode their IP in their application. It's not >> working at all on ipv6-only. > > Yeah, looks like that: > > furry@Wintermute:~>sudo tcpdump -i en0 -s 1500 -n 'net > 64:ff9b::6ca0:0/120 or net 108.160.172.0/24' > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on en0, link-type EN10MB (Ethernet), capture size 1500 bytes > 14:59:48.934365 ARP, Request who-has 108.160.172.193 tell > 169.254.64.90, length 28 > 14:59:49.323255 ARP, Request who-has 108.160.172.204 tell > 169.254.64.90, length 28 > 14:59:50.019231 ARP, Request who-has 108.160.172.193 tell > 169.254.64.90, length 28 > 14:59:50.420251 ARP, Request who-has 108.160.172.204 tell > 169.254.64.90, length 28 Seems to be a know issue: https://www.dropboxforum.com/hc/communities/public/questions/203283805-IPv6-Support- "After checking in with our engineering team, unfortunately we can't commit to a timeline for IPv6 access right now. " However I do see some difference between 'not support v6' and 'hardcode v4 addresses' ;-\ -- SY, Jen Linkova aka Furry
Re: [ipv6-wg] IPv6-only network at RIPE70
On Tue, May 12, 2015 at 2:50 PM, Jérôme Fleury wrote: > I suspect Dropbox to hardcode their IP in their application. It's not > working at all on ipv6-only. Yeah, looks like that: furry@Wintermute:~>sudo tcpdump -i en0 -s 1500 -n 'net 64:ff9b::6ca0:0/120 or net 108.160.172.0/24' tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on en0, link-type EN10MB (Ethernet), capture size 1500 bytes 14:59:48.934365 ARP, Request who-has 108.160.172.193 tell 169.254.64.90, length 28 14:59:49.323255 ARP, Request who-has 108.160.172.204 tell 169.254.64.90, length 28 14:59:50.019231 ARP, Request who-has 108.160.172.193 tell 169.254.64.90, length 28 14:59:50.420251 ARP, Request who-has 108.160.172.204 tell 169.254.64.90, length 28 I'll follow up on this... > On the contrary, I'm pleasantly surprised to see that Cisco DTLS VPN > works over NAT64. > > Thanks for giving us a sandbox, that is really interesting. Great to know, thanks for the feedback! > > > On Mon, May 11, 2015 at 5:41 AM, Jen Linkova wrote: >> Sorry, a very important part was missed in my email: >> >> Big thanks to Cisco Systems (Eric Vynce, Steve Simlo and Andrew >> Yourtchenko in particular) for providing with NAT64 solution and to >> RIPE NCC for building this network and proving that IPv6 does work! >> IPv6-only network @RIPE would have never happened without their help! >> >> My apologies for not mentioning this in my email in the first place. >> >> On Mon, May 11, 2015 at 1:46 PM, Jen Linkova wrote: >>> I'm glad to announce that there is a IPv6-only (with NAT64) network at >>> RIPE70. >>> >>> Please note that this experimental network is not supported by the >>> RIPE NCC or RIPE 67 Technical Team and is offered on a best-effort >>> basis. >>> >>> How to connect: >>> >>> - Make sure IPv6 is enabled on your device >>> - Connect to SSID: IPV6ONLYEXP >>> - Enter the password: iknowbesteffort >>> >>> Please note that NAT64&DNS64 is used to provide connectivity to >>> IPv4-only resources, so use DNS servers information provided by the >>> network. >>> >>> If you see any connectivity issues: >>> - connect to the 'normal' dual-stack one; >>> - if connecting to dual-stack network solves the issue, please email >>> me (furr...@gmail.com) with details, I'd love to know about any >>> problems. >>> >>> General feedback (do you guys see any value in such an experiment, >>> what was your experience etc) is appreciated. >>> >>> -- >>> SY, Jen Linkova aka Furry >> >> >> >> -- >> SY, Jen Linkova aka Furry >> -- SY, Jen Linkova aka Furry
Re: [ipv6-wg] IPv6-only network at RIPE70
Sorry, a very important part was missed in my email: Big thanks to Cisco Systems (Eric Vynce, Steve Simlo and Andrew Yourtchenko in particular) for providing with NAT64 solution and to RIPE NCC for building this network and proving that IPv6 does work! IPv6-only network @RIPE would have never happened without their help! My apologies for not mentioning this in my email in the first place. On Mon, May 11, 2015 at 1:46 PM, Jen Linkova wrote: > I'm glad to announce that there is a IPv6-only (with NAT64) network at RIPE70. > > Please note that this experimental network is not supported by the > RIPE NCC or RIPE 67 Technical Team and is offered on a best-effort > basis. > > How to connect: > > - Make sure IPv6 is enabled on your device > - Connect to SSID: IPV6ONLYEXP > - Enter the password: iknowbesteffort > > Please note that NAT64&DNS64 is used to provide connectivity to > IPv4-only resources, so use DNS servers information provided by the > network. > > If you see any connectivity issues: > - connect to the 'normal' dual-stack one; > - if connecting to dual-stack network solves the issue, please email > me (furr...@gmail.com) with details, I'd love to know about any > problems. > > General feedback (do you guys see any value in such an experiment, > what was your experience etc) is appreciated. > > -- > SY, Jen Linkova aka Furry -- SY, Jen Linkova aka Furry
[ipv6-wg] IPv6-only network at RIPE70
I'm glad to announce that there is a IPv6-only (with NAT64) network at RIPE70. Please note that this experimental network is not supported by the RIPE NCC or RIPE 67 Technical Team and is offered on a best-effort basis. How to connect: - Make sure IPv6 is enabled on your device - Connect to SSID: IPV6ONLYEXP - Enter the password: iknowbesteffort Please note that NAT64&DNS64 is used to provide connectivity to IPv4-only resources, so use DNS servers information provided by the network. If you see any connectivity issues: - connect to the 'normal' dual-stack one; - if connecting to dual-stack network solves the issue, please email me (furr...@gmail.com) with details, I'd love to know about any problems. General feedback (do you guys see any value in such an experiment, what was your experience etc) is appreciated. -- SY, Jen Linkova aka Furry
[ipv6-wg] RIPE70 Draft Agenda
Dear IPv6 WG members, RIPE70 is less than a month away and IPv6 WG is going to have two sessions, both on Thu, May 14th: - session #1: 09:00 - 10:30 (overlaps with DNS WG session); - session #2: 16:00 - 17:30 (overlaps with Database WG session). Please find the draft agenda below. NB: This time we are planning to have some informal discussion on IPv6 deployment bumps so please, please get ready to actively participate in the session! === Session 1, Thu, May 14th, 9:00 - 10:30 === A. Administrativia B. "HTTP state management (cookie) in an IPv6 world: apply caution!", Eric Vynke C. “Use Cases for IPv6 Extension Headers - Let's do some Marketing”, Wilhelm Boeddinghaus D. "OS Behavior in Contradicting Environments" , Enno Rey E. “IPv6 for ISP”, Aaron Hughes === Session2, Thu, May 14thm 16:00 - 17:30 === A. Administrativia B. WG Chair replacement procedure discussion C. "IPv6 - who is and who isn't" Geoff Huston D. Lighting talks: d1. "Lost stars”, Natalie Trenaman, d2. “Software & IPv6”, Natalie Trenaman d3. "554,631 - what's the next IPV6 speed-bump?" Jan Zorz E. IPv6 deployment bumps discussion/brainstorming session === If you have any questions/comments/concerns please do not hesitate to contact WG chairs (ipv6-wg-cha...@ripe.net) or reply to this email. -- SY, Jen Linkova aka Furry - on behalf of IPv6 WG chairs.
Re: [ipv6-wg] [atlas] What to do with RIPE Atlas probes that have only a ULA as IPv6 address?
On Wed, Mar 25, 2015 at 5:31 PM, Philip Homburg wrote:
> The RIPE Atlas team has a question what to do with probes that have only
> a Unique Local IPv6 Unicast Address (ULA) [RFC4193] as their IPv6
> address. The question is whether to treat those probes as IPv6 capable
> or not.
> As a way of dealing with this problem, the RIPE Atlas system now tags
> probes that have broken IPv6. Any probe that has an IPv6 address (other
> than link local) but cannot reach the global internet is tagged as "IPv6
> Doesn't Work" (see https://atlas.ripe.net/docs/probe-tags/)
>
> At the moment, around 2800 probes are connected and have an IPv6
> address. Of those probes, around 350 (12.5%) are tagged that IPv6
> doesn't work. Of those 350 probes, 114 have the surprising condition
> that the connect system call fails immediately with the error 'Network
> is unreachable.'
>
> Those 114 probes have two things in common, they have only a ULA address
> and the do not have a default route. It is the lack of default route
> that causes the connect system call to fail immediately.
>
> This feature (ULA and no default route) is specified in RFC-7084 (IPv6
> CE Router Requirements) requirement ULA-5 ("An IPv6 CE router MUST NOT
> advertise itself as a default router with a Router Lifetime greater than
> zero whenever all of its configured and delegated prefixes are ULA
> prefixes.") The surprising thing is that for some probes this condition
> persists for many months.
One of the possible reasons might be that a home network does not have
IPv6-enabled uplink but
ULAs are used for internal connectivity. I actually did it at my place
at some point, when I wanted to have Ipv6-enalbed LAN but my ISP did
not provide me with v6 connectivity.
114 out of 350 does look like a lot (on the other hand a lot of probes
are hosted by network people who love to play with their home
networks; )
I do hope that this situation is not caused by ISPs using ULAs
> For the Atlas project, the question is how we should treat these probes.
> Currently they are regarded as having broken IPv6 connectivity. However,
> an alternative is to consider those probes as having no IPv6 at all.
What difference does it make?
> Broader questions are: are CPEs doing the right thing here. Should a CPE
> announce a ULA on the local LAN even if there hasn't been any IPv6
> internet connectivity for a very long time? It is already complex enough
> for normal users to understand that there is always a link local IPv6
> address even if there is no IPv6 connectivity. Now we have to add ULA to
> that group as well.
If ULA is configured in a CPE, then it should be announced in RAs. As long as it
does not break v6 for users (and it should not as there is not default
route), it's fine.
> 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.
But, again, could you please clarify what is the difference between
two tags from practical perspective?
--
SY, Jen Linkova aka Furry
[ipv6-wg] Last Call: "IPv6 Troubleshooting for Residential ISP Helpdesks"
Hello, At IPv6 WG session in London, we discussed the most recent version of the "IPv6 Troubleshooting for Residential ISP Helpdesks" document. The proposed plan of action was to reach the consensus on the technical details of the document and then publish it (as combined IPv6 WG and BCOP TF effort). This email announces the working group last call for the "IPv6 Troubleshooting for Residential ISP Helpdesks" document. Please read the most recent version of it: https://www.ripe.net/ripe/groups/tf/bcop/ipv6-troubleshooting-for-residential-isp-helpdesks and provide your comments to the list *until 23:59 Fri Dec 19th 2014*. Thanks! -- SY, Jen Linkova aka Furry
Re: [ipv6-wg] [address-policy-wg] [Merging ipv6 and address policy mailing lists]
On Wed, Nov 12, 2014 at 8:32 AM, Aleksi Suhonen wrote: >> Should we put address policy wh together with IPv6 wg? Why we need >> two different wg for addressing? Because IPv6 WG is not for addressing. IPv6 is not 'IPv4 with bigger address space'. >the day we start treat IPv6 as normal >> IP address is the day we really in a world of v6. I have no objection to *this* statement, so I'd expect that all discussions related to IPv[4,6] address policy are happening in this mailing list, while IPv6 WG discusses technical aspects of IPv6 deployment. > In theory, the IPv6 working group and mailing lists are not only about > address policy. Exactly. >In practice, I do think that a separate mailing list for > IPv6 at RIPE has outlived its usefulness. I strongly disagree. Shall I read it as a proposal to shut down IPv6 WG as well? I'd object to say the least. There are a lot of topics to discuss on IPv6 WG which do not belong to address policy. Anyway, I'm surprised to see a discussion about shutting down a mailing list happening in *another* mailing list. If community feels like 'there is nothing to discuss in IPv6 WG mailing list anymore' (which does not seem to be a case as I can see from the replies to your message), it should be discussed there. I'm adding ipv6-wg@ to Cc: so people are aware of this discussion, however from my point of view we've seen enough support to keep IPv6 list untouched. -- SY, Jen Linkova aka Furry
Re: [ipv6-wg] IPv6 & Android & Facebook
On Tue, Oct 21, 2014 at 4:33 PM, Daniel Baeza (Red y Sistemas TVT) wrote: > I'm writting here since I didnt really know how or where to check whats > happening to us. I'd say that it sounds more like a question people ask in ipv6-...@lists.cluenet.de mailing list, but as we are here, let me try.. > Is any of you experiencing problems loading photos/images from > facebook/twitter/instagram/whatever via Android devices with Dual-Stack > IPv4/IPv6? I don't. Works fine. However I'm afraid it's hard to say anything about your problem w/o more details. Are you talking about dual-stack wifi connection? Have you tried http://www.test-ipv6.com? [shot in the dark] MTU issue? -- SY, Jen Linkova aka Furry
