[ppml] IPv6 flawed?
Cort Buffington
cort at kanren.net
Mon Sep 17 13:57:50 EDT 2007
We are one of the "old school" state RENs. Our business is WAN
networking to connect institutions with a research and/or educational
mission together and to the Internet, Internet 2 (as appropriate),
etc. Over the course of our existence, we have gathered a fair number
of support servers performing various functions for ourselves and our
members, as well as co-location of servers for members within our PoPs.
We do not terminate VPNs, and in fact, because of limitations
associated with traditional VPN-V4 L3 MPLS where services like
Multicast and IPv6 have been concerned, we don't use that technology
(much - we have the luxury of being able to not use it for the most
part). We do have a great many downstream members (members to us,
most would call them "customers") who use our IP space. One of them
is very active with IPv6 (a larger community college of all places,
not a major university), and I understand they simply made prefix
changes much as we did, as they planned for this eventuality when
they initially deployed.
We became fully operational with IPv6 in 2004. Yes, there have been
issues -- spotty vendor support being a big one -- but we did it
because as an R&E network (Research and Education) it is our mission
to do things like this so that we can (hopefully) be ahead of the
curve. Rather than a specific case study, my poorly made point was
that many issues arising with IPv6 since we've been using it have
been because we are thinking 4 and not thinking 6. The size of the
address space in and of itself has made a lot of things better, but
not from a "we're out of addresses" standpoint. It has made it
possible to more logically break down a network, change prefixes (as
I mentioned earlier), and have member networks (customers) that don't
have several tiny networks they're trying to send to us because
addresses are such a precious commodity small incremental growth and
contiguous space are not possible. With IPv6's address space it's
easy to throw someone hundreds, or thousands of /64s and not even be
over-allocating. So, even though we may not have fixed the routing
paradigm, at least we only see ONE PREFIX coming from the downstream
instead of several, so that's one routing table entry, and one prefix
for them to send to a second provider when they multihome. Not
necessarily glamorous, but there are things about 6 that do work and
are working. The challenge is thinking 6 and thinking what 6 can or
will do instead of letting our minds be locked into the limitations
of IPv4. Now, that wasn't a great example of how great IPv6 might be,
but it shows how thinking in 6 can solve some problems. Making a lot
of small things a little better amounts to a lot of improvement over
time.
Sadly, (I believe it was Paul Vixie that mentioned it) IPv6 did not
address the routing paradigm, but there are some nice things it did
address. In my case, something was improved. And I believe there is a
lot more good out there to be gleaned from it. If we ever see things
(really working, and working well) like authentication and encryption
built into IPv6 via extension headers, maybe we won't even need VPNs
as we know them today.
On Sep 17, 2007, at 11:30 AM, Dave Mohler wrote:
> I'm sorry you felt dismissed by Owen's request. I have no idea if
> Owen
> knows of the network on which you did the IPv6 renumbering, but I'm
> sure
> I don't have any idea and I'm sure many other list readers don't know
> your network.
>
> I feel that these are reasonable questions that help the group
> understand the implications of IPv6 renumbering. I assumed that
> Owen's
> inclusion of his reasons for asking were just as a means of explaining
> the importance of the questions for the benefit of the discussion and
> not an advanced dismissal of your contribution. (Perhaps they were
> not
> worded in the best way, but in general I've felt that I could trust
> most
> list contributors' motives as being for the good of the group.)
>
> I, for one, would appreciate your answers to Owen's questions to
> help us
> better understand the issues.
>
> Thanks for your contributions!
>
> David A. Mohler
> Senior Network Specialist
> Graceland University
>
>
>> -----Original Message-----
>> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf
> Of
>> Cort Buffington
>> Sent: Monday, September 17, 2007 11:09 AM
>> To: Owen DeLong
>> Cc: ppml at arin.net
>> Subject: Re: [ppml] IPv6 flawed?
>>
>> Yep, that's right. I really don't do enough meaningful networking to
>> speak up here. I should have kept my mouth shut.
>>
>> On Sep 17, 2007, at 10:58 AM, Owen DeLong wrote:
>>
>>> 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.
>>>
>>>
>>
>> --
>> 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.
>
--
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
More information about the ARIN-PPML
mailing list