Re: IPv6 will never fly: ARIN continues to kill it

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> >> That helps, but understanding of IPv6 and mindshare is even harder than
> >> forklift upgrades.
> >>     
> >
> > 	I'll agree that it is hard.  That's why the clue x 4 keeps having
> > 	to be applied.
> >   
> That's a LOT of people to whack on the side of the head.  And it pretty
> much has to be done in meatspace; the net doesn't help you out with this
> problem.
> >> And if you start
> >> looking for technology that would let you automate renumbering your
> >> entire network, you might find that the technology that exists is
> >> incomplete and unproven.
> >
> > 	Which is why I keep saying.  Run through the renumbering exercise.
> > 	Find the problems.  Report them to your vendors.  Vendors being
> > 	proactive would be a big help here.
> >   
> Yes they would.  But basically everyone can assume that this is Somebody
> Else's Problem.  You want to make it the problem for the network admins,
> sysadmins, users, application writers, and firewall vendors to solve. 
> Those people  want to make it the problem for the carrier ISPs and
> router vendors to solve.

	I've spent a lot of time adding support to make renumbering
	easier in the places that I can change.  I will continue
	to do that.

	I can't however fix every problem.

> And really, fixing the routing system so that it can provide stable
> global PI addresses to everyone (say, via something LISP-like) might be
> easier...especially that the need to renumber isn't the only problem
> that lack of stable global PI addresses causes.
> 
> >> oh yes, and practical use of DNS security still seems to
> >> elude us.
> >
> > 	It will as long as people don't actually sign there zones.
> > 	Have you asked for cs.utk.edu to be signed?
> >   
> I don't work there any more, so it's Somebody Else's Problem.  :)
> 
> And really, there's no way I'd trust DNS to do this.  I've spent too
> many years watching it break.

	It breaks much less often once you allow it to be automated.
	We could in theory have all nameservers update the parent
	servers with appropriate glue.  This is not technically hard
	to do.  Similarly NS RRsets.
 
> Keith
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews@xxxxxxx

_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]