[ppml] IPv6 flawed?

[Kevin Kargel]

Cort,
	Wouldn't both of your examples have the same difficulty no
matter how the network was renumbered?  Devices outside of ones control
are just that, and if you change your PI/PA space they are going to need
to be adjusted by their local admin, by that admin's policy.  This 'may'
be ameliorated by using DNS for resolution, but again, that is the
admin's policy to decide.
	Connected networks need communication between admins for smooth
connectivity during transitions..  
Kevin

> -----Original Message-----
> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On 
> Behalf Of Owen DeLong
> Sent: Monday, September 17, 2007 10:59 AM
> To: Cort Buffington
> Cc: ppml at arin.net
> Subject: Re: [ppml] IPv6 flawed?
> 
> Please expand on the following details of your ease of renumbering:
> 
> 	1.	How many VPNs did you have terminating on devices in the
> 		space you renumbered at one end with the other 
> end terminating
> 		on devices you did not control?
> 
> 	2.	How many external organizations had firewalls 
> you don't control
> 		with policies containing your addresses when 
> you renumbered?
> 
> If your answers to questions 1 and 2 are zero or near zero, 
> then, I would argue that you have not demonstrated a 
> meaningful difference in the effort required to renumber IPv6 
> vs. IPv4.
> 
> Owen
> 
> On Sep 17, 2007, at 8:39 AM, Cort Buffington wrote:
> 
> > My organization recently changed IPv6 numbers. We had used EUI64 
> > addressing on servers and used a "subnetting" scheme that 
> was logical 
> > and sustainable. It did not require actually touching any 
> servers to 
> > change IPs. It was done as such: Add IP prefix to 
> appropriate router 
> > interfaces, run find-replace script to fix prefixes in DNS, wait, 
> > remove old IP prefixes from router interfaces.
> >
> > While I  am not trying to diminish the valid conversation about 
> > difficulties involved in renumbering, etc., I am actually 
> doing, and 
> > have done this. IPv6 is not IPv4, and there are some aspects of it 
> > that change the ways things are/can be done. In our experience, the 
> > largest hurdle involved in using IPv6 effectively is 
> getting folks to 
> > break out of the IPv4 way of thinking. With larger address 
> spaces come 
> > the ability to address interfaces, etc. in a more logical way, that 
> > when added to some of the nice things like EUI64 
> addressing, can make 
> > "re-numbering" considerably easier.
> >
> >
> > On Sep 17, 2007, at 10:26 AM, Azinger, Marla wrote:
> >
> >> Hmmm...Now...what was that long drawn out conversation....that 
> >> addressed private space in a good way.....oh yeah!  ULA-C!
> >>
> >> Cheers!
> >> Marla
> >>
> >> -----Original Message-----
> >> From: ppml-bounces at arin.net 
> [mailto:ppml-bounces at arin.net]On Behalf 
> >> Of Brian Johnson
> >> Sent: Monday, September 17, 2007 7:00 AM
> >> To: Ted Mittelstaedt; Kevin Kargel; ppml at arin.net
> >> Subject: Re: [ppml] IPv6 flawed?
> >>
> >>
> >> Ted wrote:
> >>>
> >>> You don't understand it because you are large enough to have your 
> >>> own allocation.
> >>>
> >>> For the orgs too small to meet justification requirements 
> to get a 
> >>> direct allocation of IPv6 from an RIR, it is a big problem.
> >>>
> >>> They do not want to get IPv6 from an ISP AKA "local internet 
> >>> registry"
> >>> and put time and money into numbering all their servers 
> and suchlike 
> >>> - because if they find a better deal down the street from 
> the ISP's 
> >>> (I mean local internet registry's) competitor, they want 
> to be free 
> >>> to dump the existing ISP and go to the competitor without 
> having to 
> >>> renumber internally.
> >>>
> >>> This IMHO is the single largest reason so many orgs adopted NAT.
> >>>
> >>
> >> I agree with Ted that there is a noticeable benefit to having NAT 
> >> capability, but not that it is the "single largest reason so many 
> >> orgs adopted NAT." It does act as a pseudo-security 
> feature, and it 
> >> does make a network "portable".
> >>
> >> I would have no problem with a say a /32 of IPv6 being set 
> aside as 
> >> "private space." This will only increase the longevity of 
> IPv6 when 
> >> used by companies who only need limited IP addresses and 
> want to use 
> >> private space and NAT. What arguments are there against this?
> >>
> >> - Brian
> >>
> >> _______________________________________________
> >> PPML
> >> You are receiving this message because you are subscribed 
> to the ARIN 
> >> Public Policy Mailing List (PPML at arin.net).
> >> Unsubscribe or manage your mailing list subscription at:
> >> http://lists.arin.net/mailman/listinfo/ppml Please contact 
> the ARIN 
> >> Member Services Help Desk at info at arin.net if you experience any 
> >> issues.
> >> _______________________________________________
> >> PPML
> >> You are receiving this message because you are subscribed 
> to the ARIN 
> >> Public Policy Mailing List (PPML at arin.net).
> >> Unsubscribe or manage your mailing list subscription at:
> >> http://lists.arin.net/mailman/listinfo/ppml Please contact 
> the ARIN 
> >> Member Services Help Desk at info at arin.net if you experience any 
> >> issues.
> >>
> >
> > --
> > Cort Buffington
> > Assistant Director for Technical Services The Kansas Research and 
> > Education Network cort at kanren.net
> > Office: +1-785-856-9800 x301
> > Mobile: +1-785-865-7206
> >
> >
> >
> > _______________________________________________
> > PPML
> > You are receiving this message because you are subscribed 
> to the ARIN 
> > Public Policy Mailing List (PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN 
> > Member Services Help Desk at info at arin.net if you experience any 
> > issues.
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to 
> the ARIN Public Policy Mailing List (PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml Please contact 
> the ARIN Member Services Help Desk at info at arin.net if you 
> experience any issues.
>