Re: [ipv6-wg] RIPE80 Call for Presentations

[Silvia Hagen]

>> 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.

>I think this is spot on; IPv6 never makes it to the top of the list for most 
>organisations.

>The difference is when something critical comes along that changes that.

I agree, I see this often. 

But to keep spirits high, I must say that I also see customers that work on it 
consistently and with a realistic long term perspective with no emergency 
pressure and even keep going in these crazy Corona times.  I guess our 
impression of what is going on and what not is also very often limited, because 
unless we're involved, we don't know much about such initiatives.

There is hope.

Silvia

-Ursprüngliche Nachricht-
Von: ipv6-wg  Im Auftrag von Tim Chown
Gesendet: Freitag, 1. Mai 2020 11:04
An: Jen Linkova 
Cc: Jens Link ; ipv6-wg@ripe.net IPv6 
Betreff: Re: [ipv6-wg] RIPE80 Call for Presentations

> On 1 May 2020, at 04:44, Jen Linkova  wrote:
> 
> 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.

I think this is spot on; IPv6 never makes it to the top of the list for most 
organisations.

The difference is when something critical comes along that changes that. 

Tim

Re: [ipv6-wg] Y.IPv6RefModel is out of scope for the ITU

[Silvia Hagen]

Fully agree with Sander and others

I was shocked when I saw this document

Cheers
Silvia

-Ursprüngliche Nachricht-
Von: ipv6-wg [mailto:ipv6-wg-boun...@ripe.net] Im Auftrag von Sander Steffann
Gesendet: Sonntag, 27. Mai 2018 14:56
An: Jim Reid
Cc: ipv6-wg@ripe.net; JORDI PALET MARTINEZ
Betreff: Re: [ipv6-wg] Y.IPv6RefModel is out of scope for the ITU

Hi,

>> Stepping back a bit, what we're discussing here is not whether address 
>> assignment / allocation models should be dealt with by the RIRs or the IETF, 
>> but whether they are in scope for the ITU.
> 
> Indeed. This is the biggest issue BY FAR with Y.IPv6RefModel. Or should be,
> 
> It would be a serious problem if this key concern got overlooked by the WG in 
> its efforts to point out the many errors and defects in that document.

+1

We should help the ITU, where the help in this case comes down to: make them 
acknowledge that this work is already handled by existing organisations and 
groups, that the ITU does not have the experience and knowledge to improve on 
that, and that they should follow the lead of the established authorities in 
this area (= IP networking) instead of making things worse by inventing 
"standards" that have no relation to reality.

Cheers,
Sander

Re: [ipv6-wg] ipv6-wg Digest, Vol 55, Issue 2

[Silvia Hagen]

That would be a great panel discussion with some diverse speakers on the panel  
:-)

Silvia

-Ursprüngliche Nachricht-
Von: ipv6-wg [mailto:ipv6-wg-boun...@ripe.net] Im Auftrag von Benedikt 
Stockebrand
Gesendet: Montag, 25. April 2016 20:14
An: christian bretterhofer
Cc: ipv6-wg@ripe.net
Betreff: 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/