[rpd] IPv4 Soft Landing BIS

Wed Aug 9 21:26:52 UTC 2017

I’ll take a stab at this…

I work for Akamai Technologies.

We have widely deployed dual stack on most of our installations and are working towards dual stacking our corporate networks as well.

For the deployments we do not have IPv6, it is usually due to the provider hosting the deployment being currently incapable of supporting it and we actively work to encourage those providers to make IPv6 available. We actively work to deploy IPv6 as soon as the provider is capable in such instances.

We have made it possible for a number of web sites to become available on IPv6 despite not yet having IPv6 support on their origin servers. Further, we are now making IPv6 available as default for all new customers and new installations with existing customers. We have seen very few situations where making content additionally available on IPv6 poses a problem for our customers and most of our customers are very appreciative of our ability to make their content dual-stack regardless of the status of their origin servers.

We are continuing to enhance our IPv6 capabilities and we truly believe that IPv6 is the only viable future for the internet.

Previously I worked for Hurricane Electric and I believe that their IPv6 track record speaks for itself.

Owen

> On Aug 6, 2017, at 23:38 , Andrew Alston <Andrew.Alston at liquidtelecom.com> wrote:
> 
> You know, I been sitting here thinking – and so here it is
>  
> I believe the way to promote v6 is not to point out negative behaviour of others or to use a stick
> I believe the way to promote v6 is to lead by example – and cite your successes – and what you are doing to promote and deploy v6 yourself – so that others can follow 
> I believe the way to ensure good behaviour with regards to v4 addressing is again – to lead by example – not penalize other networks
>  
> Basically – my biggest problem (amongst others) with both this v4 soft landing policy and the review policy – are that they are outward facing, they attack other networks, rather than rewarding good behaviour.  There is a tendency that I see to attack other networks, and members, based on their v4 and v6 stances, rather than looking inwards and saying, how do we reward those who are doing the RIGHT thing, and what are WE doing to promote v6, to ensure its deployment, to get it out there.
>  
> After all – there is an age old saying that says – people in glass houses should not throw rocks.
>  
> And so, I want to issue a challenge to the authors of the review policy and the soft landing policy – because the answers may go a long way to shifting a lot of peoples mindsets, and I do this not to attack you, but to give you the chance to demonstrate that these policies are not there to attack other people, they are an extension of your leading by example.
>  
> Tell this list – who do YOU work for – what is their v6 position – how deployed is it – what are the challenges you are facing to get it out there – lead by example
> To the authors of the review policy – similar questions – is all of your space announced?  Are you prepared to disclose your utilization percentages?  - lead by example.
>  
> As for myself – if anyone here wishes to debate or discuss my v6 readiness stance or the work done in promoting v6 that I’ve done – happy to do so – in any forum – on any list – at any time.
>  
> Thanks
>  
> Andrew
>  
>  
> From: Andrew Alston [mailto:Andrew.Alston at liquidtelecom.com <mailto:Andrew.Alston at liquidtelecom.com>] 
> Sent: 07 August 2017 09:00
> To: Arnaud AMELINA <amelnaud at gmail.com <mailto:amelnaud at gmail.com>>; Owen DeLong <owen at delong.com <mailto:owen at delong.com>>
> Cc: rpd >> AfriNIC Resource Policy <rpd at afrinic.net <mailto:rpd at afrinic.net>>
> Subject: Re: [rpd] IPv4 Soft Landing BIS
>  
> Arnaud,
>  
> Firstly, the ISP you refer to (I had to figure out which one it was, and it didn’t take long to work this out, since there is only one that matches criteria).
>  
> Your numbers cited are *VASTLY* misleading – over 500 prefix’s – this is true – however – let’s be real for a second and actually aggregate those prefix’s before we start screaming about space.
>  
> Aggregated – they announce a total of 9 prefix’s – they are all subsets of the same block – the number of prefix’s here is pretty meaningless.  While I don’t agree with the massive level of de-aggregation here, its probably done as an anti-hijack mechanism, *shrug* fact is – the number you cited – is a total misnomer.
>  
> Secondly – that particular ISP – is a DSL provider – now – let me explain a few things about DSL in South Africa
>  
> There is no naked DSL to my knowledge as of right now – (As of the 3rd of April 2017 there certainly wasn’t and the country has been asking for such for more years than I can count)
> Without naked DSL – native provision of v6 to the consumer is impossible – and unless you control the CPE there is no way to tunnel v6 back to the customer either – since that would have to be manually configured
>  
> Effectively – they have no real means of getting v6 to the vast majority of their customers – so why announce it?  For what purpose?  You announce space you are using – not space you are announcing to show off that you can.  
>  
> Please – before citing figures that are misleading, and making statements that penalize specific companies – understand the market you are talking about – and check the numbers to ensure they are actually accurate and fair.
>  
> And quite frankly, do I believe said ISP should be able to get more v4 space?  100% I do – they are using it – that is probably either the largest or second largest DSL provider in the country – they are connecting users – their space is in active use – and I’d rather see them announcing their current roughly /14.5 worth of space and using it, than see a /22 sitting around not used for 10 years.  If people need the space – and can actively use it to connect customers to the Internet today – 100% they should be allowed to have it and use it.
>  
> Andrew
>  
> P.S – For the record – I have absolutely zero relationship to the ISP in question – nor have I ever done any work for them and have no bias in what I am saying above – I would say the same for any ISP in the position they are in.
>  
>  
>  
>  
> From: Arnaud AMELINA [mailto:amelnaud at gmail.com <mailto:amelnaud at gmail.com>] 
> Sent: 04 August 2017 18:50
> To: Owen DeLong <owen at delong.com <mailto:owen at delong.com>>
> Cc: rpd >> AfriNIC Resource Policy <rpd at afrinic.net <mailto:rpd at afrinic.net>>
> Subject: Re: [rpd] IPv4 Soft Landing BIS
>  
> Hi Owen, Hi Community , see in lines
>  
> Le 31 juil. 2017 17:54, "Owen DeLong" <owen at delong.com <mailto:owen at delong.com>> a écrit :
> >>>> combined with the failure to implement IPv6
> >>>> at a similar level because it has the same kind of cost-shifting effect.
> >>>>
> >>>>> But using your analogy, please help me understand how the two liken,
> >>>>> who is dumping what on who, and which side is facing any costs as a
> >>>>> result.
> >>>>
> ...
> >>
> >>
> >
> > As an example: There is a residential ISP in South Africa who has over 500 IPv4 prefixes. How many IPv6 prefixes do they announce? None. ZERO. You are saying that this operator should be allowed as much more IPv4 space as they can get, until it runs out, and tough luck to the new IPv6 operator down the line who needs IPv4 to connect to the legacy Internet. I'm sorry, I can not, and won't support the continued distribution of IPv4 resources to existing operators to maintain the IPv4 status quo.
> 
> Not at all… If you want to write a policy that resolves this issue without the other baggage and problems present in this policy, I would support a clean policy designed to address that issue and make space available to ANYONE specifically for IPv6 to IPv4 connectivity/transition. In fact, I wrote such a policy in the ARIN region years ago and it is now NRPM section 4.10 in the ARIN region.
> >
> >
> 
> I don't really know how things work in ARIN region, but the proposal which led to section 4.10 of ARIN NRPM was authored by Alain Durand.
>  
> https://www.arin.net/policy/proposals/2008_5.html <https://www.arin.net/policy/proposals/2008_5.html>
> http://lists.arin.net/pipermail/arin-ppml/2008-June/011277.html <http://lists.arin.net/pipermail/arin-ppml/2008-June/011277.html>
>  
>  
> Thanks
>  
> Regads 
> 
> Arnaud. 
> 
> _______________________________________________
> RPD mailing list
> RPD at afrinic.net <mailto:RPD at afrinic.net>
> https://lists.afrinic.net/mailman/listinfo/rpd <https://lists.afrinic.net/mailman/listinfo/rpd>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20170809/08268325/attachment-0001.html>