Provider IPv6 Deployment

Can anyone share resources on deploying IPv6 in a provider network? Most all documentation I find is from the customer perspective; which is great and all, but what about setting up dhcpv6-pd, what about the relay agent, or what about an equivalent of dhcp option 82? Nich

RIPE NCC Global IPv6 Deployment Survey

Hi, just a little reminder that there are a few days left to help the RIPE NCC by filling up our Global IPv6 Deployment Survey. We have already received a considerable amount of responses, but would like to hear from more people. The goal of the survey is to get an overview of IPv6 deployment

TIMELY - Fwd: RIPE NCC Global IPv6 Deployment Survey

NANOGers - An important reminder: this Global IPv6 deployment survey is closing at the end of March. If you have a moment, please take the time to complete this survey so that the RIRs may collectively have a better understanding of the status of IPv6 deployment in the Internet. Thanks

RIPE NCC Global IPv6 Deployment Survey

Dear colleagues, The RIPE NCC would like to invite you to participate in its Global IPv6 Survey 2018. The goal of the survey is to get an overview IPv6 deployment across the world, and to assess how this is seen from the perspective of ISPs and Enterprise users. The 2018 survey is a follow up

Verizon Wireless IPv6 deployment contact?

Is there anyone from Verizon Wireless that I can talk to regarding IPv6 deployment? I am getting nonsensical answers from my local contacts. Please contact me off-list. thanks, -Randy

Re: Questions on IPv6 deployment

On Tue, Jan 17, 2017 at 5:13 PM, Matthew Huff wrote: > Please check the nanog archives. > I was just responding to the argument that a /64 is wasteful and serves > little purpose. Then respond. With explanation, reasoning and evidence. Telling me to search a massive archive for

Re: Questions on IPv6 deployment

On Tue, Jan 17, 2017 at 6:06 PM, Sander Steffann wrote: > One thing that comes to mind is that it seems that some routers only have > limited space in their routing tables for prefixes longer than a /64. If you > would configure a /127 on the link but push the /64 to the

Re: Questions on IPv6 deployment

Hi Bill, > Op 17 jan. 2017, om 22:55 heeft William Herrin het volgende > geschreven: > > I'm always interested in learning something new. Please explain the > DOS vectors you're referring to and how they're mitigated by > allocating a /64 to the point to point link. One thing

RE: Questions on IPv6 deployment

7 4:56 PM > To: Matthew Huff <mh...@ox.com> > Cc: Michael Still <stillwa...@gmail.com>; nanog@nanog.org > Subject: Re: Questions on IPv6 deployment > > On Tue, Jan 17, 2017 at 4:07 PM, Matthew Huff <mh...@ox.com> wrote: > > The reason for allocating a /64 for

Re: Questions on IPv6 deployment

On 1/17/17 1:55 PM, William Herrin wrote: > On Tue, Jan 17, 2017 at 4:07 PM, Matthew Huff wrote: >> The reason for allocating a /64 for a point to point link is due to various >> denial of service attack vectors. if you mean allocating a /127, then... sure. Neighbor discovery on

Re: Questions on IPv6 deployment

On Tue, Jan 17, 2017 at 4:07 PM, Matthew Huff wrote: > The reason for allocating a /64 for a point to point link is due to various > denial of service attack vectors. Hi Matthew, I'm always interested in learning something new. Please explain the DOS vectors you're referring to

Re: Questions on IPv6 deployment

To: Michael Still <stillwa...@gmail.com> >> Cc: nanog@nanog.org >> Subject: Re: Questions on IPv6 deployment >> >> On Tue, Jan 17, 2017 at 12:48 PM, Michael Still <stillwa...@gmail.com> >> wrote: >>> http://nabcop.org/index.php/IPv6_Subnetting >&g

RE: Questions on IPv6 deployment

ent: Tuesday, January 17, 2017 4:02 PM > To: Michael Still <stillwa...@gmail.com> > Cc: nanog@nanog.org > Subject: Re: Questions on IPv6 deployment > > On Tue, Jan 17, 2017 at 12:48 PM, Michael Still <stillwa...@gmail.com> > wrote: > > http://nabcop.org/index.php/IP

Re: Questions on IPv6 deployment

On Tue, Jan 17, 2017 at 12:48 PM, Michael Still wrote: > http://nabcop.org/index.php/IPv6_Subnetting That's overall good advice. I quibble with a couple of points: 1. If you plan to use a /126 on a point to point and can't imagine how you would use a /64 on that point to

Re: Questions on IPv6 deployment

d to use a /64 for PtP interfaces and I’ve read use a /128 >> instead.Assign all loopbacks from the same /64, use a different /64 for >> each loopback. Ect, ect. >> >> I’m trying not to light a religious war but what is the current best >> practice for

Re: Questions on IPv6 deployment

r some direction/reading list of how to properly configure > IPv6. I’ve read to use a /64 for PtP interfaces and I’ve read use a /128 > instead.Assign all loopbacks from the same /64, use a different /64 for > each loopback. Ect, ect. > > I’m trying not to light a religious

Re: Questions on IPv6 deployment

Hi, > Suggest /128's for loopbacks and /124's for point to points, all from > the same /64. This way you don't burn space needlessly, don't open > yourself to neighbor discovery issues on point to points I usually reserve one /64 for loopbacks, reserve a /64 per point-to-point connection and

Re: Questions on IPv6 deployment

On Mon, Jan 16, 2017 at 10:11 AM, Matthew Crocker wrote: > I’m looking for some direction/reading list of how to properly configure > IPv6. I’ve read to use a /64 for PtP interfaces and I’ve read use a /128 > instead.Assign all loopbacks from the same /64, use a

Re: Questions on IPv6 deployment

gt; IPv6. I’ve read to use a /64 for PtP interfaces and I’ve read use a /128 > instead.Assign all loopbacks from the same /64, use a different /64 for > each loopback. Ect, ect. > > > > I’m trying not to light a religious war but what is the current best > practice for

Re: Questions on IPv6 deployment

, ect. I’m trying not to light a religious war but what is the current best practice for IPv6 deployment in a service provider network? PS. I’ll be at NANOG69 in DC next month, 1st NANOG for me after 22 years. ☺ At the start, the advice was to configure individual /64 for loopbacks, however

Questions on IPv6 deployment

, ect. I’m trying not to light a religious war but what is the current best practice for IPv6 deployment in a service provider network? PS. I’ll be at NANOG69 in DC next month, 1st NANOG for me after 22 years. ☺ -Matt -- Matthew Crocker Crocker Communications, Inc. President

Re: Kudos to Rogers Wireless on IPv6 deployment

- Original Message - > From: "Ida Leung" > [ ... ... ] Fido Internet > is > coming! Cool! My gateway is 1:3603/150. Who do I poll? Cheers, -- jra -- Jay R. Ashworth Baylink

Re:Kudos to Rogers Wireless on IPv6 deployment

Yes, we have started the IPv6 enablement of our wireless network. West was completed dual stack on Sept 29, Ontario will come next then east region. Rogers Internet has completed all the IPv6 enablement. Fido Internet is coming! Please email me directly for your IPv6 experience with

Re: Kudos to Rogers Wireless on IPv6 deployment

I'm also seeing IPv6 on Rogers 4g/LTE on an Android in Winnipeg! Looks like I'm part of 2605:8d80:400::/38 Theodore Baschak - AS395089 - Hextet Systems https://ciscodude.net/ - https://hextet.systems/ http://mbix.ca/ > On Oct 1, 2016, at 10:37 PM, Hugo Slabbert wrote: > > So

Re: Kudos to Rogers Wireless on IPv6 deployment

On Sat, 1 Oct 2016, Hugo Slabbert wrote: So, kudos, Rogers Wireless! http://labs.apnic.net/cgi-bin/ccpagev6?c=CA Sort on "samples". Seems Telus and Rogers are the only top10 with any double digit % IPv6 users. Telus is at 65-70%, that's a really good number. -- Mikael Abrahamsson

Re: Kudos to Rogers Wireless on IPv6 deployment

> On Oct 1, 2016, at 8:37 PM, Hugo Slabbert wrote: > > So, kudos, Rogers Wireless! This has also been live on Roger's Fido sub-brand for a while now, too. 2605:8d80:484:: is live in Vancouver. --lyndon

Kudos to Rogers Wireless on IPv6 deployment

So frequently on this list we hear people asking/begging their providers for IPv6 roadmaps or chastising them for the lack of same, that I thought it might be nice to actually give props to a provider actually moving the needle. I was pleasantly surprised today to notice an IPv6 address on my

Re: IPv6 Deployment for Mobile Subscribers

RFC 6177: This document obsoletes RFC 3177, updating its recommendations in the following ways: 1) It is no longer recommended that /128s be given out. While there may be some cases where assigning only a single address may be justified, a site, by definition,

Re: IPv6 Deployment for Mobile Subscribers

On Fri, 22 Jul 2016 10:54:48 +0200, Ricardo Ferreira said: > Is there anyone here working in an ISP where IPv6 is deployed? > We are starting to plan the roll-out IPv6 to mobile subscribers (phones) I > am interesting in knowing the mask you use for the assignment; whether it > is /64 or /128. > >

Re: IPv6 Deployment for Mobile Subscribers

* Baldur Norddahl > Den 22. jul. 2016 20.25 skrev "Ca By" : > > > Phones, as in 3gpp? If so, each phone alway gets a /64, there is > > no choice. > > > > https://tools.ietf.org/html/rfc6459 > > Here the cell companies are marketing their 4G LTE as an alternative > to DSL,

Re: IPv6 Deployment for Mobile Subscribers

NOG <nanog-boun...@nanog.org> on behalf of Baldur Norddahl <baldur.nordd...@gmail.com> Sent: Friday, July 22, 2016 4:10:41 PM To: nanog@nanog.org Subject: Re: IPv6 Deployment for Mobile Subscribers Den 22. jul. 2016 20.25 skrev "Ca By" <cb.li...@gmail.com>: > Phones, a

Re: IPv6 Deployment for Mobile Subscribers

Den 22. jul. 2016 20.25 skrev "Ca By" : > Phones, as in 3gpp? If so, each phone alway gets a /64, there is no choice. > > https://tools.ietf.org/html/rfc6459 Here the cell companies are marketing their 4G LTE as an alternative to DSL, Coax and fiber for internet access in

Re: IPv6 Deployment for Mobile Subscribers

Good day, On 22 Jul 2016, at 10:54, Ricardo Ferreira wrote: > Is there anyone here working in an ISP where IPv6 is deployed? I am not, but I can answer from the consumer's point of view: > Basically a sole device will be connecting to the internet so I am > wondering if this rule is follwed.

Re: IPv6 Deployment for Mobile Subscribers

On Friday, July 22, 2016, Ricardo Ferreira wrote: > Is there anyone here working in an ISP where IPv6 is deployed? > We are starting to plan the roll-out IPv6 to mobile subscribers (phones) I > am interesting in knowing the mask you use for the assignment; whether it

Re: IPv6 Deployment for Mobile Subscribers

uly 22, 2016 12:57:58 PM To: Ricardo Ferreira Cc: NANOG Subject: Re: IPv6 Deployment for Mobile Subscribers Ricardo, I know from previous discussions on this list that Android phones are looking for DHCPD leases and not /128's or /64's. From what I remember this is due to the current requirement

Re: IPv6 Deployment for Mobile Subscribers

Ricardo, I know from previous discussions on this list that Android phones are looking for DHCPD leases and not /128's or /64's. From what I remember this is due to the current requirement for multiple ipv6 subnets for various applications (vpns among others) to function correctly. As a result

IPv6 Deployment for Mobile Subscribers

Is there anyone here working in an ISP where IPv6 is deployed? We are starting to plan the roll-out IPv6 to mobile subscribers (phones) I am interesting in knowing the mask you use for the assignment; whether it is /64 or /128. In RFC 3177, it says: 3. Address Delegation Recommendations The

Re: IPv6 deployment excuses

On 11/07/2016 09:24, Mark Andrews wrote: >> Our provider sale representative, who is the most tech savvy sale-rep I >> ever encountered by far, which is not a very high bar, but still, said >> something like: >> "You shouldn't worry about that, we have plenty of IPv4 addresses >> left... and

Re: IPv6 deployment excuses

t; so probably have broader experience than the NANOG archives. > > > > Can we have a thread summarising the most common excuses you've heard, > > and if they are actual problems blocking IPv6 deployment or just down > > to ignorance? Perhaps this could be the basis for an FAQ

Re: IPv6 deployment excuses

o a lot of selection-bias in the NANOG membership > base but you deal with a lot of enterprise networks off of this list > so probably have broader experience than the NANOG archives. > > Can we have a thread summarising the most common excuses you've heard, > and if they are actu

Re: IPv6 deployment excuses

quot;Valdis Kletnieks" <valdis.kletni...@vt.edu> Cc: nanog@nanog.org Sent: Monday, July 4, 2016 11:22:59 PM Subject: Re: IPv6 deployment excuses valdis.kletni...@vt.edu wrote: >> A large ISP should just set up usual NAT. In addition, > Thus almost guaranteeing a ca

Re: IPv6 deployment excuses

On Tue, 5 Jul 2016, Baldur Norddahl wrote: We will tell you to use IPv6 for that or make you pay extra for a dedicated IPv4 address. That is a good solution to that problem. I hope all ISPs implementing A+P protocols does that. It also puts a monthly cost that teleworkers have to pay (or

Re: IPv6 deployment excuses

On 5 July 2016 at 07:27, Mikael Abrahamsson wrote: > On Mon, 4 Jul 2016, Baldur Norddahl wrote: > > The two other technologies mentioned do the same as MAP more or less, but >> both requires carrier NAT, which is expensive for the ISP and has a lack of >> control as seen from

Re: IPv6 deployment excuses

On Mon, 4 Jul 2016, Baldur Norddahl wrote: The two other technologies mentioned do the same as MAP more or less, but both requires carrier NAT, which is expensive for the ISP and has a lack of control as seen from the end user point of view (no port forwarding etc). What it does however, is

Re: IPv6 deployment excuses

valdis.kletni...@vt.edu wrote: A large ISP should just set up usual NAT. In addition, Thus almost guaranteeing a call to the support desk for each and every single game console, because the PS3 and PS4 doesn't have a configuration interface for that, and the XBox probably doesn't either (and

Re: IPv6 deployment excuses

On Tue, 05 Jul 2016 11:16:31 +0900, Masataka Ohta said: > A large ISP should just set up usual NAT. In addition, the ISP > tells its subscriber a global IP address, a private IP address > and a small range of port numbers the subscriber can use and > set up *static* bi-directional port

Re: IPv6 deployment excuses

> On Jul 4, 2016, at 10:32 PM, Matt Hoppes > wrote: > > Jared, > The issue I have with the whole DNS IPv6 thing is IPs are static (on > infrastructure), DNS can get munged up and is another database we have to > maintain. I’m not sure I understand your

Re: IPv6 deployment excuses

Jared Mauch wrote: Are you saying, without NAT or something like that to restrict reachable ports, the Internet, regardless of whether it is with IPv4 or IPv6, is not very secure? I'm saying two things: 1) UPnP is a security nightmare and nobody (at scale) will let you

Re: IPv6 deployment excuses

Jared, The issue I have with the whole DNS IPv6 thing is IPs are static (on infrastructure), DNS can get munged up and is another database we have to maintain. So now rather than just maintaining an IP database we have to maintain a database for DNS to IP and the IP. And Ina subscriber

Re: IPv6 deployment excuses

Or how about we just avoid anything that uses the terms like "Mappings" and "NAT" and speed the adoption of IPv6 everywhere which already solves all of these problems. *Spencer Ryan* | Senior Systems Administrator | sr...@arbor.net *Arbor Networks* +1.734.794.5033 (d) | +1.734.846.2053 (m)

Re: IPv6 deployment excuses

Baldur Norddahl wrote: With end to end NAT, you can still configure your UPnP capable NAT boxes to restrict port forwarding. Only if you by NAT mean "home network NAT". No large ISP has or will deploy a carrier NAT router that will respect UPnP. A large ISP should just set up usual NAT. In

Re: IPv6 deployment excuses

On Mon, Jul 04, 2016 at 06:41:00PM +0900, Masataka Ohta wrote: > Jared Mauch wrote: > > > Actually they are not that great. Look at the DDoS mess that UPnP has > > created and problems for IoT (I call it Internet of trash, as most > > devices are poorly implemented without safety in mind) folks

Re: IPv6 deployment excuses

On Monday, July 4, 2016, Baldur Norddahl wrote: > On 2016-07-04 20:50, Ca By wrote: > > > Always so funny how people love talking how great MAP scales, yet it has > never been deployed at scale. 464XLAT and ds-lite have been deployed at > real scale, so has 6RD. > >

Re: IPv6 deployment excuses

On 2016-07-04 20:50, Ca By wrote: Always so funny how people love talking how great MAP scales, yet it has never been deployed at scale. 464XLAT and ds-lite have been deployed at real scale, so has 6RD. MAP is like beta max. Technically great, but reality is poor. The two MAP RFCs are dated

Re: IPv6 deployment excuses

On 4/Jul/16 18:28, Matt Hoppes wrote: > Except the lady will eventually downsize. The college student will want more > and lease the space. > > Also, the 49,000 Sq ft office space that has been leased for 10 years and > never occupied will be taken back and released to someone who will

Re: IPv6 deployment excuses

On 4/Jul/16 16:33, Matt Hoppes wrote: > Except that IPv4 is not exhausted. That's the doomsday message that was > preached over and over. > > The simple fact that there is/are IP broker exchanges now simply proves there > are surplus IPs to go around. > > We have an efficiency utilization

Re: IPv6 deployment excuses

On 4/Jul/16 14:44, Matt Hoppes wrote: > I disagree. Any data center or hosting provider is going to continue to offer > IPv4 lest they island themselves from subscribers who have IPv4 only - which > no data center is going to do. But that's what I said... Mark.

IPv6 deployment excuses

On Monday, July 4, 2016, Baldur Norddahl > wrote: > On 4 July 2016 at 11:41, Masataka Ohta > wrote: > > > With end to end NAT, you can still configure your UPnP capable NAT > >

Re: IPv6 deployment excuses

On 4 July 2016 at 11:41, Masataka Ohta wrote: > With end to end NAT, you can still configure your UPnP capable NAT > boxes to restrict port forwarding. > Only if you by NAT mean "home network NAT". No large ISP has or will deploy a carrier NAT router that will

Re: IPv6 deployment excuses - IPv6 only resources

On Mon, Jul 4, 2016 at 11:55 AM, Jacques Latour wrote: > > Is there a list of IPv6 only ISP or services? I'd be curious to trend > that somehow, by geography, service type, etc... if any. > Since "IPv6 only" right now is primarily about those portions of the network

Re: IPv6 deployment excuses

Filip Hruska wrote: Without firewalls, internet is not very secure, regardless of protocol used. Irrelevant. The point of the Internet with end to end transparency is that if end users want to have the end to end transparency, they can have it. If they don't, they don't have to.

RE: IPv6 deployment excuses - IPv6 only resources

: Tore Anderson; nanog@nanog.org >Subject: Re: IPv6 deployment excuses > > >In message c2ae05bcc...@rivervalleyinternet.net>, Matt Hoppes writes: >> I disagree. Any data center or hosting provider is going to continue >> to offer IPv4 lest they island themselves from subscri

Re: IPv6 deployment excuses

On Mon, Jul 4, 2016 at 11:28 AM, Matt Hoppes < mattli...@rivervalleyinternet.net> wrote: > Except the lady will eventually downsize. The college student will want > more and lease the space. > > Also, the 49,000 Sq ft office space that has been leased for 10 years and > never occupied will be

Re: IPv6 deployment excuses

On Mon 2016-Jul-04 12:42:33 -0400, Christopher Morrow wrote: On Mon, Jul 4, 2016 at 12:28 PM, Matt Hoppes < mattli...@rivervalleyinternet.net> wrote: Except the lady will eventually downsize. The college student will want more and lease the space. Also, the 49,000

Re: IPv6 deployment excuses

On Mon, Jul 4, 2016 at 12:28 PM, Matt Hoppes < mattli...@rivervalleyinternet.net> wrote: > Except the lady will eventually downsize. The college student will want > more and lease the space. > > Also, the 49,000 Sq ft office space that has been leased for 10 years and > never occupied will be

Re: IPv6 deployment excuses

On Mon, 4 Jul 2016, Matt Hoppes wrote: My point is there are more than enough IPv4 addresses. The issue is not resources. It is hoarding and inappropriate use. I tend to make the analogy of land use and/or houses/apartments. Yes, there is that old lady down the street who lives in 300 square

Re: IPv6 deployment excuses

On 4 July 2016 at 17:33, Matt Hoppes wrote: > The simple fact that there is/are IP broker exchanges now simply proves there > are surplus IPs to go around. I'm unsure of the message. Is the statement that if commodity is tradable, there is surplus to go

Re: IPv6 deployment excuses

Except that IPv4 is not exhausted. That's the doomsday message that was preached over and over. The simple fact that there is/are IP broker exchanges now simply proves there are surplus IPs to go around. We have an efficiency utilization issue - not an exhaustion issue.

Re: IPv6 deployment excuses

There are 7 billion people world wide that want Internet and only approximately 3 billion usable IPv4 addresses. It wont do. Den 4. jul. 2016 16.03 skrev "Matt Hoppes" < mattli...@rivervalleyinternet.net>: > My point is there are more than enough IPv4 addresses. The issue is not > resources. It

Re: IPv6 deployment excuses

we do, the utility of IPv4 will probably start to degrade pretty rapidly as more attention and focus is placed on IPv6 connectivity. If that happens and you're still an IPv4 only edge/access network that hasn't even begun planning an IPv6 deployment? That's apt to be an uncomfortable experience.

Re: IPv6 deployment excuses

My point is there are more than enough IPv4 addresses. The issue is not resources. It is hoarding and inappropriate use. The large ISPs have enough IPs to service every household in the US several times over. And yet, we have an IP shortage. There are universities holding onto /8s and not

Re: IPv6 deployment excuses

In message , Matt Hoppes writes: > I disagree. Any data center or hosting provider is going to continue to > offer IPv4 lest they island themselves from subscribers who have IPv4 > only - which no data center is going to do. > > One

Re: IPv6 deployment excuses

I disagree. Any data center or hosting provider is going to continue to offer IPv4 lest they island themselves from subscribers who have IPv4 only - which no data center is going to do. One can not run IPv6 only because there are sites that are only IPv4. Thus, as an ISP you can safely

Re: IPv6 deployment excuses

Without firewalls, internet is not very secure, regardless of protocol used. On 07/04/2016 11:41 AM, Masataka Ohta wrote: > Jared Mauch wrote: > >> Actually they are not that great. Look at the DDoS mess that UPnP has >> created and problems for IoT (I call it Internet of trash, as most >>

Re: IPv6 deployment excuses

Jared Mauch wrote: Actually they are not that great. Look at the DDoS mess that UPnP has created and problems for IoT (I call it Internet of trash, as most devices are poorly implemented without safety in mind) folks on all sides. Are you saying, without NAT or something like that to restrict

Re: IPv6 deployment excuses

On 4/Jul/16 11:04, Tore Anderson wrote: > My point is that as a content provider, I only need dual-stacked > façade. That can easily be achieved using, e.g., protocol translation > at the outer border of my network. > > The inside of my network, where 99.99% of all the complexity, devices, >

Re: IPv6 deployment excuses

* Mark Tinka > What I was trying to get to is that, yes, running a single-stack is > cheaper (depending on what "cheaper" means to you) than running > dual-stack. Wholeheartedly agreed. > That said, running IPv4-only means you put yourself at a disadvantage > as IPv6 is

Re: IPv6 deployment excuses

On 3/Jul/16 15:34, Tore Anderson wrote: > We've found that it is. IPv6-only greatly reduces complexity compared to > dual stack. This means higher reliability, lower OpEx, shorter recovery > time when something does go wrong anyway, fewer SLA violations, happier > customers, and so on - the

Re: IPv6 deployment excuses

* Mark Tinka > I understand your points - to your comment, my question is around > whether it is cheaper (for you) to just run IPv6 in lieu of IPv6 and > IPv4. We've found that it is. IPv6-only greatly reduces complexity compared to dual stack. This means higher reliability, lower OpEx, shorter

Re: IPv6 deployment excuses

On 3 July 2016 at 12:15, Mark Tinka wrote: > > > On 3/Jul/16 12:01, Ruairi Carroll wrote: > > > Core of the issue is that we _need_ to get an ICMP message back to the > original "real server" who sent it. It's a non-issue in the SP space, but > imagine if your ECMP groups

Re: IPv6 deployment excuses

On 3/Jul/16 12:01, Ruairi Carroll wrote: > > Core of the issue is that we _need_ to get an ICMP message back to the > original "real server" who sent it. It's a non-issue in the SP space, > but imagine if your ECMP groups were stateful in both directions... Okay. > > > Think about it in

Re: IPv6 deployment excuses

On 3 July 2016 at 11:42, Mark Tinka wrote: > > > On 2/Jul/16 17:35, Ruairi Carroll wrote: > > - ECMP issues (Mostly around flow labels and vendor support for that, also > feeds back into PMTUD issues) > > > Do you rely on the ToS field in IPv4 for ECMP? > > Nope. I use l4

Re: IPv6 deployment excuses

On 2/Jul/16 18:49, William Astle wrote: > Their specific excuse du jour changes every few months but it usually > boils down to "we don't want to put any effort or resources into > updating anything". If you keep asking your girlfriend out on a date each week, and she refuses to go out with

Re: IPv6 deployment excuses

On 2/Jul/16 17:35, Ruairi Carroll wrote: > - ECMP issues (Mostly around flow labels and vendor support for that, also > feeds back into PMTUD issues) Do you rely on the ToS field in IPv4 for ECMP? > - Maintaining 2x IP stacks is inherently expensive Vs 1 How so? Mark.

RE: IPv6 deployment excuses

way you had set them, I am quite sure that you take an entirely different position! > -Original Message- > From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Mike Hammett > Sent: Saturday, 2 July, 2016 12:43 > Cc: nanog list > Subject: Re: IPv6 deployment excuse

Re: IPv6 deployment excuses

Living in an area where we have a dense pocket without broadband available is a key problem. The two incumbents fail to service the area despite one having fiber 1200' away at the entry to our street. One area incumbent can do native v6, the other does 6rd but they don't serve the area so

Re: IPv6 deployment excuses

- Original Message - From: "Keith Medcalf" <kmedc...@dessus.com> To: "nanog list" <nanog@nanog.org> Sent: Saturday, July 2, 2016 11:41:48 AM Subject: RE: IPv6 deployment excuses Yes, the default is "on". An exception is added for EVERY SINGLE PIECE of

Re: IPv6 deployment excuses

On Sat, Jul 02, 2016 at 10:49:40AM -0600, William Astle wrote: > it usually boils down to "we don't want to put any effort or resources into > updating anything". > And they must be right as their clients won't go away... :p

Re: IPv6 deployment excuses

There's one other major issue faced by stub networks which I have encountered at $DAYJOB: - My upstream(s) refuse(s) to support IPv6 This *is* a deal breaker. The pat response of "get new upstreams" is not helpful and shows the distinct bias among this community to the large players who

RE: IPv6 deployment excuses

now because I never ran it. > -Original Message- > From: Spencer Ryan [mailto:sr...@arbor.net] > Sent: Saturday, 2 July, 2016 10:08 > To: Keith Medcalf > Cc: North American Network Operators' Group > Subject: RE: IPv6 deployment excuses > > Windows 8 and 10 with the mo

RE: IPv6 deployment excuses

Windows 8 and 10 with the most recent service packs default the firewall to on with very few inbound exemptions. On Jul 2, 2016 11:38 AM, "Keith Medcalf" wrote: > > > There is no difference between IPv4 and IPv6 when it comes to > > firewalls and reachability. It is worth

RE: IPv6 deployment excuses

> There is no difference between IPv4 and IPv6 when it comes to > firewalls and reachability. It is worth noting that hosts which > support IPv6 are typically a lot more secure than older IPv4-only > hosts. As an example every version of Windows that ships with IPv6 > support also ships with the

Re: IPv6 deployment excuses

Issues I've faced in the past with v6 deployments, from the point of view of stub networks. Feel free to pick/choose as you wish: - Badly understood (By the team) methods to assign addressing to servers. - Poor tooling in regards to log processing/external providers. - Unknown cost in dev time to

Re: IPv6 deployment excuses

Thanks guys, this is what I have come up with so far. Next week i'll put together a web page or something with slightly better write-ups, but these are my initial ideas for responses to each point. Better answers would be welcome. "We have NAT, therefore we don't need IPv6." "We still have plenty

Re: IPv6 deployment excuses

Actually they are not that great. Look at the DDoS mess that UPnP has created and problems for IoT (I call it Internet of trash, as most devices are poorly implemented without safety in mind) folks on all sides. The fact that I go to a hotel and that AT mobility have limited internet reach is

Re: IPv6 deployment excuses

Jared Mauch wrote: https://youtu.be/v26BAlfWBm8 Is always good for a reminder and laughs on a holiday weekend. But, end to end NATs are actually good: https://tools.ietf.org/html/draft-ohta-e2e-nat-00 fully transparent to all the transport and application layer protocols. And, to

RE: IPv6 deployment excuses

> Subject: Re: IPv6 deployment excuses > > On Fri Jul 1 17:43:21 2016, Gary Wardell wrote: > > > > > > <http://ipv6excuses.com/> http://ipv6excuses.com/ > > > > That website only supports IPv4. > > It’s on your side. > > alarig@

Re: IPv6 deployment excuses

From: Alarig Le Lay -- Sent: 2016-07-01 - 14:53 > On Fri Jul 1 17:43:21 2016, Gary Wardell wrote: >> > >> > http://ipv6excuses.com/ >> >> That website only supports IPv4. > > It’s on your side. > > alarig@pikachu ~ % telnet ipv6excuses.com http > Trying

Re: IPv6 deployment excuses

On Fri Jul 1 17:43:21 2016, Gary Wardell wrote: > > > > http://ipv6excuses.com/ > > That website only supports IPv4. It’s on your side. alarig@pikachu ~ % telnet ipv6excuses.com http Trying 2403:7000:8000:500::26... Connected to ipv6excuses.com. Escape character is '^]'. ^] telnet> quit

RE: IPv6 deployment excuses

> > http://ipv6excuses.com/ That website only supports IPv4. Gary

  1   2   3   4   >