why use IPv6, was: Lazy network operators

haesu at towardex.com haesu at towardex.com
Sun Apr 18 19:11:49 UTC 2004


> >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 at towardex.com                  Boston-based Colocation & Bandwidth Services
cell: 1(978)-394-2867           web: http://www.towardex.com , noc: www.twdx.net



More information about the NANOG mailing list