cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
596
Views
0
Helpful
8
Replies

IPV4 vs IPV6 discussion

Clutz5250
Level 1
Level 1

Here and there, i see posts on the interwebs that invite crusaders for IPV6, and I don't think the position typically held during said conversations holds a mature enough perspective. I'm hoping i can get some views here with Cisco engineers and see their opinion as to things like low level, hardware processing trade offs and maybe some of other paradigm shifts that might get missed typically?

Here are my own points of thought:
1. In my mind, a smaller bitwise footprint is always cheaper and faster.
2. 'No NAT' is not guaranteed with an IPV6 deployment.
3. publicly routable endpoints opens greater visibility into company networks
4. load performance and bottlenecks shifting over time due to greater public IPV6 provisioning

Any input is welcome. Thanks!

 

8 Replies 8

@Clutz5250 

 Not sure if I understood you post. But I believe the discussion about which is better or appropriate was left behind.  IPV6 was adopted by ISP due obivous reason, they did not have anymore IPv4 to use.

  Companies, in the other side,  dont need to embrace IPV6 because IPV4 is enough to attend even the biggest company in the world. No one want to strugle with IPV6 if IPv4 is working just fine.

Hopefully i can redirect to a more edifying route here between us. So, in my opinion, exhaustion (alone) isn't a big enough motivator. Like you said, companies don't need to embrace IPV6 so much, or at least the pressure is less. However, in some of the conversations I've been exposed to, the thought is to run with public IPV6 all over the place internally, like its just dandy okay thing to do, and there's no draw backs. Assuming that NAT isn't needed in said IPV6 deployment (because it would defeat the incentive), then it seems security concerns get hand waived when putting public IPV6 on things like endpoints.

Not necessarily I would say, as IPv6 address can be used only for local network.   I trully  believe that the motivation or lack of motivation to move toward IPV6 is due the  trouble of having to reconfigure the whole network, which sometimes , does not support IPV6 in all the devices

So, if you're going to go with a local network IPV6 scheme, then why worry about IPV6 at all? Invariably it means that said traffic for users would get NAT'ed anyway when going offnet. I suppose its still forward thinking to build out IPV6 regardless, but it doesn't have a lot of incentive to convert it at that point.

In a prod network segment with a bunch of dynamic things getting scaled, public IPV6 would make more sense.

Joseph W. Doherty
Hall of Fame
Hall of Fame

Any or all of your four points could be discussed, but the proverbial elephant on the room is IPv4 address space exhaustion.  Unless that's addressed (pun unintended) your four points are rather moot.  Sort of like rearranging the deck chairs on the Titanic.  What's your thoughts on that?

BTW, I'm not a particular booster of IPv6, as I personally think some of the IPv6 approach, in some aspects, is deja vu of IPv4.


@Joseph W. Doherty wrote:

Any or all of your four points could be discussed, but the proverbial elephant on the room is IPv4 address space exhaustion.  Unless that's addressed (pun unintended) your four points are rather moot.  Sort of like rearranging the deck chairs on the Titanic.  What's your thoughts on that?

BTW, I'm not a particular booster of IPv6, as I personally think some of the IPv6 approach, in some aspects, is deja vu of IPv4.


I think NAT bought us a lot more time, but you are right. However, internal public IPV6 all over internal spaces raises my eyebrows.  I don't think it really gets rid of NAT and pushing for a completely routable public space, internally, kind of sounds reckless (at least off the bat). I could see IPV6 NATs on edges to solve exhaustion issues, but the incentive after that just gets blurry (for me).

Hmm, one of your primary concerns, with using IPv6, is using public IPs internally?

If so, private IPv4 IPs behind a NAT device, does add Security through Obscurity, but that's generally considered a weak security approach.  Also NAT, or more precisely the more often used PAT, brings it's own issues.

Also consider, IPv4's common usage of NAT, evolved more, I believe, as a method to slow IPv4 address space exhaustion, I suspect, initially, IPv4 designers expected hosts connected to the Internet would all have public IPs.  Otherwise, doesn't really make any sense to provide anyone a public Class A address block.

Ramblin Tech
Spotlight
Spotlight

Enterprises will migrate to IPv6 when the cost-benefit of using it is greater than that of IPv4. That is, when it is seen as more cost-effective to obtain or deliver some service over IPv6 than IPv4. Right now, it is hard to see what that IPv6 service driver will be for enterprises, as long as IPv4 is cost-effective. If ever ISPs started charging more for IPv4 connectivity than IPv6 (due to IPv4 exhaust), that might start the migration (assuming all Internet resources were equally accessible via IPv6).

SPs & web-scalers, OTOH, are already seeing some use-cases where it makes business sense to implement as IPv6. For example, some 5G mobility SPs have implemented IPv6 as the only transport for user & control traffic in their backhaul networks, with no IPv4 addressing of 5G components. The backhaul GTP tunnels (think of GTP as GRE for mobility) having IPv6 headers, but encapsulating the end-users' IPv4/v6 traffic. It is possible in the future that SRv6 might entirely replace GTP in mobility networks, as SRv6 is seen by some operators as having great SDN traffic-engineering potential (and having advantages over IPv4 SR-MPLS). SRv6 might be a driver for IPv6 adoption in the future for both SPs and enterprises. Maybe.

Disclaimer: I am long in CSCO
Review Cisco Networking for a $25 gift card