nanog mailing list archives
Re: why use IPv6, was: Lazy network operators
From: haesu () towardex com
Date: Sun, 18 Apr 2004 15:11:49 -0400
Renumbering is much easier.I like this one.
Now this is a funny one about IPv6. How is renumbering *any* easier than IPv4? Yes you have autoconf based on route advertisements/solicits on the client end from the routers, but how is that any different than IPv4+DHCP? Is it perhaps b/c IPv6 uses "classful" styled numbering scheme? (i.e. you have /64 to end sites, where you simply s/old:old:old:old/new:new:new:new/ ) There is also a doc about renumbering in IPv6 http://ietfreport.isoc.org/idref/draft-baker-ipv6-renumber-procedure/ I guess it is easier to renumbering in IPv6, but even in IPv4, a proper set of procedures and well-done planning can make renumbering process way less painful than anticipated.
Multihoming can be done the same way many people do it for IPv4: take addresses from one ISP and announce them to both. Obviously your /48 will be filtered, but as long as you make sure it isn't filtered between your two ISPs, you're still reachable when the link to either fails. However, this means renumbering when switching to another primary ISP. Not much fun, despite the fact that renumbering is much easier in IPv6.
??? How is this any different than bungled up peering with the 2nd provider with half-way transit? If my /48 is filtered from GRT, but at least both of my upstreams see it, I don't see it as multihoming. I see it as Broken multihoming. Another issue... How is IPv6 going to solve aggregation problem is something still being worked on..... Making TLA spaces requirement for multihoming, like in RFC2772 is helping a lot in aggregation at the GRT, but that is definately a sledgehammer. honestly, in my sole belief, IPv6 surely integrates many of the more recent makeshift additions of IPv4, right into the protocol itself, which is a very good thing. But still, doesn't have enough real-world justification for most enterprises to plan for immediate protocol upgrade to v6, especially when multihoming issues are still not cleared, and most of improvements are already done in IPv4 with add-on's. -J -- James Jun TowardEX Technologies, Inc. Technical Lead Network Design, Consulting, IT Outsourcing james () towardex com Boston-based Colocation & Bandwidth Services cell: 1(978)-394-2867 web: http://www.towardex.com , noc: www.twdx.net
Current thread:
- RE: Lazy network operators, (continued)
- RE: Lazy network operators Paul Jakma (Apr 17)
- Re: why use IPv6, was: Lazy network operators Iljitsch van Beijnum (Apr 18)
- Re: why use IPv6, was: Lazy network operators John Curran (Apr 18)
- Re: why use IPv6, was: Lazy network operators Todd Vierling (Apr 19)
- Re: why use IPv6, was: Lazy network operators Patrick W . Gilmore (Apr 18)
- Re: why use IPv6, was: Lazy network operators Iljitsch van Beijnum (Apr 18)
- Re: why use IPv6, was: Lazy network operators Paul Jakma (Apr 18)
- Re: why use IPv6, was: Lazy network operators Iljitsch van Beijnum (Apr 19)
- Re: why use IPv6, was: Lazy network operators Carlos Friacas (Apr 19)
- RE: Lazy network operators Paul Jakma (Apr 17)
- Re: why use IPv6, was: Lazy network operators Patrick W . Gilmore (Apr 18)
- Re: why use IPv6, was: Lazy network operators haesu (Apr 18)
- Re: why use IPv6, was: Lazy network operators Paul Jakma (Apr 18)
- RE: Lazy network operators Alex Bligh (Apr 18)
- Re: Lazy network operators Petri Helenius (Apr 18)
- Re: Lazy network operators Randy Bush (Apr 19)
- Re: Lazy network operators Petri Helenius (Apr 25)
- Re: Lazy network operators Kurt Erik Lindqvist (Apr 20)