<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=utf-8">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7235.2">
<TITLE>Help</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<BR>
<P><FONT SIZE=2>--------------------------<BR>
Sent from my BlackBerry Wireless Handheld<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: ppml-bounces@arin.net <ppml-bounces@arin.net><BR>
To: ppml@arin.net <ppml@arin.net><BR>
Sent: Wed Jul 25 21:57:26 2007<BR>
Subject: PPML Digest, Vol 25, Issue 71<BR>
<BR>
Send PPML mailing list submissions to<BR>
ppml@arin.net<BR>
<BR>
To subscribe or unsubscribe via the World Wide Web, visit<BR>
<A HREF="http://lists.arin.net/mailman/listinfo/ppml">http://lists.arin.net/mailman/listinfo/ppml</A><BR>
or, via email, send a message with subject or body 'help' to<BR>
ppml-request@arin.net<BR>
<BR>
You can reach the person managing the list at<BR>
ppml-owner@arin.net<BR>
<BR>
When replying, please edit your Subject line so it is more specific<BR>
than "Re: Contents of PPML digest..."<BR>
<BR>
<BR>
Today's Topics:<BR>
<BR>
1. Re: Dean Anderson, 130.105.0.0/16 and the future of the IPv4<BR>
Internet. (Owen DeLong)<BR>
2. Re: Soliciting comments: IPv4 to IPv6 fast migration (Owen DeLong)<BR>
3. Re: EPO (Robert Bonomi)<BR>
4. Re: Dean Anderson, 130.105.0.0/16 and the future of the IPv4<BR>
Internet.] (Dean Anderson)<BR>
5. Re: Soliciting comments: IPv4 to IPv6 fast migration<BR>
(Keith W. Hare)<BR>
6. Re: Soliciting comments: IPv4 to IPv6 fast migration<BR>
(William Herrin)<BR>
7. Re: Soliciting comments: IPv4 to IPv6 fast migration<BR>
(William Herrin)<BR>
8. Re: Soliciting comments: IPv4 to IPv6 fast migration<BR>
(William Herrin)<BR>
9. Re: Soliciting comments: IPv4 to IPv6 fast migration<BR>
(JORDI PALET MARTINEZ)<BR>
<BR>
<BR>
----------------------------------------------------------------------<BR>
<BR>
Message: 1<BR>
Date: Wed, 25 Jul 2007 17:59:28 -0700<BR>
From: Owen DeLong <owen@delong.com><BR>
Subject: Re: [ppml] Dean Anderson, 130.105.0.0/16 and the future of<BR>
the IPv4 Internet.<BR>
To: Dean Anderson <dean@av8.com><BR>
Cc: Paul Vixie <vixie@vix.com>, ppml@arin.net<BR>
Message-ID: <E9271818-C83C-4192-BCE3-A9E46E48B785@delong.com><BR>
Content-Type: text/plain; charset=US-ASCII; format=flowed<BR>
<BR>
Actually, it is not. There is a process for addressing that documented<BR>
on the ARIN website and nowhere does it suggest posting such an<BR>
accusation to the PPML.<BR>
<BR>
<A HREF="http://www.arin.net/about_us/boardguidelines.html#removal">http://www.arin.net/about_us/boardguidelines.html#removal</A><BR>
<BR>
So, Dean, I suggest you go try and recruit either 10% of the members in<BR>
good standing or a majority of the BoT to make an appropriate petition<BR>
or motion.<BR>
<BR>
Owen<BR>
<BR>
On Jul 25, 2007, at 3:16 PM, Dean Anderson wrote:<BR>
<BR>
> Its not the right forum to discuss the details of Vixie and crony<BR>
> finances.<BR>
><BR>
> But, I believe this is the right forum for discussing the details of<BR>
> ARIN Board Member misconduct, and its relation to false claims about<BR>
> 130.105/16 being hijacked/disused.<BR>
><BR>
> --Dean<BR>
><BR>
><BR>
> On Wed, 25 Jul 2007, David Williamson wrote:<BR>
><BR>
>> On Wed, Jul 25, 2007 at 01:27:54PM -0400, Dean Anderson wrote:<BR>
>>> While this isn't really the right forum,<BR>
>><BR>
>> That's absolutely correct. Please please PLEASE take this somewhere<BR>
>> else. This has zero to do with ARIN policy.<BR>
>><BR>
>> -David<BR>
>><BR>
>><BR>
><BR>
> --<BR>
> Av8 Internet Prepared to pay a premium for better service?<BR>
> www.av8.net faster, more reliable, better service<BR>
> 617 344 9000<BR>
><BR>
><BR>
> _______________________________________________<BR>
> This message sent to you through the ARIN Public Policy Mailing List<BR>
> (PPML@arin.net).<BR>
> Manage your mailing list subscription at:<BR>
> <A HREF="http://lists.arin.net/mailman/listinfo/ppml">http://lists.arin.net/mailman/listinfo/ppml</A><BR>
<BR>
<BR>
<BR>
------------------------------<BR>
<BR>
Message: 2<BR>
Date: Wed, 25 Jul 2007 18:07:51 -0700<BR>
From: Owen DeLong <owen@delong.com><BR>
Subject: Re: [ppml] Soliciting comments: IPv4 to IPv6 fast migration<BR>
To: "William Herrin" <arin-contact@dirtside.com><BR>
Cc: ARIN Address Policy <ppml@arin.net><BR>
Message-ID: <77053E98-C998-4094-8970-C6213947B4A6@delong.com><BR>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed<BR>
<BR>
I have some comments on the proposal as follows:<BR>
<BR>
1. It is very unnecessarily complex.<BR>
2. Do you really think that the required 6to4 functionality can be<BR>
widely enough deployed in less than 4 months?<BR>
3. This would make the 6to4 address range a permanent encampment<BR>
of legacy v4 holders and preserve all of the issues related to the <BR>
swamp.<BR>
We should not give up on the v6 transition as an opportunity to <BR>
drain the<BR>
swamp. Enshrining the swamp in a permanent IPv6 map is<BR>
counter-productive.<BR>
4. This proposal (and 6to4 in general) appear to ignore what happens<BR>
when sites have IPv4 addresses, native IPv6 connectivity, but, no<BR>
longer have native IPv4 connectivity.<BR>
<BR>
I oppose the proposal as written.<BR>
<BR>
Owen<BR>
<BR>
<BR>
<BR>
------------------------------<BR>
<BR>
Message: 3<BR>
Date: Wed, 25 Jul 2007 20:44:15 -0500 (CDT)<BR>
From: Robert Bonomi <bonomi@mail.r-bonomi.com><BR>
Subject: Re: [ppml] EPO<BR>
To: ppml@arin.net<BR>
Message-ID: <200707260144.l6Q1iFbI005782@s25.firmware.com><BR>
<BR>
> From owner-nanog@merit.edu Wed Jul 25 15:53:45 2007<BR>
> Date: Wed, 25 Jul 2007 12:10:11 -0700<BR>
> To: nanog@merit.edu<BR>
><BR>
><BR>
> Leo Bicknell wrote:<BR>
> > I was complaining to some of the power designers during the building<BR>
> > of a major facility that the EPO button represented a single point<BR>
> > of failure, and effectively made all of the redundancy built into<BR>
> > the power system useless. After all, what's the point of having<BR>
> > two (or more) of anything, if there's one button somewhere that<BR>
> > turns it all off?<BR>
><BR>
<BR>
It seems to me -- without digging into 'code' compliance reqirements -- that<BR>
one could profit from some of the 'positive control' designs used in<BR>
missle silos, nuclear submarines, and the like.<BR>
<BR>
Where, to trigger the function, *two* 'buttons' must be pushed. And the<BR>
buttons are located such that a single person cannot reach both simultaneously.<BR>
<BR>
Requiring '2 of 2' buttons to trigger eliminates false positives, but<BR>
doubles the risk of 'false negatives' if a button malfunctions. This<BR>
issue can be ameliorated by providing 'more than 2' buttons, while requiring<BR>
only two buttons pushed to trigger. '2 of 3' will work properly unless there<BR>
is a _double_ failure -- intentional or accidental.<BR>
<BR>
Particularly for a building-wide 'kill' switch, this would seem to be a<BR>
prudent design.<BR>
<BR>
A passive design turns out to be fairly simple. Requirements, in minimal form<BR>
is a DPDT swith in each box, and 3-wire daisy-chain interconnect.<BR>
Use 'ring' wiring, with both ends tied to the master control, and even a<BR>
break (single) in the wiring does not a failure make.<BR>
<BR>
<BR>
<BR>
<BR>
------------------------------<BR>
<BR>
Message: 4<BR>
Date: Wed, 25 Jul 2007 22:34:46 -0400 (EDT)<BR>
From: Dean Anderson <dean@av8.com><BR>
Subject: Re: [ppml] Dean Anderson, 130.105.0.0/16 and the future of<BR>
the IPv4 Internet.]<BR>
To: Paul Vixie <paul@vix.com><BR>
Cc: ppml@arin.net<BR>
Message-ID:<BR>
<Pine.LNX.4.44.0707252227080.20640-100000@citation2.av8.net><BR>
Content-Type: TEXT/PLAIN; charset=US-ASCII<BR>
<BR>
On Thu, 26 Jul 2007, Paul Vixie wrote:<BR>
<BR>
> we will never know if dean actually believes that the UN is going to<BR>
> take over the governance of the united states of america, or if he<BR>
> just says that kind of stuff to amuse us or to amuse himself.<BR>
<BR>
I've never said that the UN is going to take over the governance of the<BR>
United States of America. I said it was possible that the UN might take<BR>
over the governance of the Internet, from the US Department of Commerce.<BR>
<BR>
One might otherwise be tempted to add "...Idiot", but your departure<BR>
from reality is truly extraordinary.<BR>
<BR>
But as we've seen that you repeatedly make entirely false statements,<BR>
I'm not too surprised by this last one. However, your pathological lying<BR>
is unbecoming and worrisome when it comes from a person entrusted with<BR>
the serious responsibilities of which you are entrusted.<BR>
<BR>
--Dean<BR>
<BR>
<BR>
<BR>
--<BR>
Av8 Internet Prepared to pay a premium for better service?<BR>
www.av8.net faster, more reliable, better service<BR>
617 344 9000 <BR>
<BR>
<BR>
<BR>
<BR>
------------------------------<BR>
<BR>
Message: 5<BR>
Date: Wed, 25 Jul 2007 22:36:14 -0400<BR>
From: "Keith W. Hare" <Keith@jcc.com><BR>
Subject: Re: [ppml] Soliciting comments: IPv4 to IPv6 fast migration<BR>
To: "ARIN Address Policy" <ppml@arin.net><BR>
Message-ID: <5c1a7aa646c813405eb2285b353cccd546a808ad@jcc.com><BR>
Content-Type: text/plain; charset="us-ascii"<BR>
<BR>
<BR>
It is not at all clear to me whether or not this proposal will speed<BR>
adoption of IPv6.<BR>
<BR>
I see a several impediments to adopting IPv6:<BR>
<BR>
1. Current ARIN policies favor Provider Agregatable (PA) address<BR>
allocations rather than Provider Independent allocations (PI). Since<BR>
IPv6 discourages NAT, this suggests that I get an IPv6 address<BR>
assignment from an ISP and number all internal resources using the ISP's<BR>
IPv6 addresses. Then, If I decide to switch ISPs, I have to renumber<BR>
everything and rewrite all firewall rules. Why would I adopt a protocol<BR>
that tied me to an ISP? <BR>
<BR>
2. I have lots of devices on the internal network that may not (or<BR>
maybe they do, I dunno) support IPv6, the temperature monitor and the<BR>
UPS, for example. These types of devices are going to slow the move to<BR>
IPv6 in the internal network.<BR>
<BR>
3. My firewalls do not currently support IPv6 and the firewall vendor<BR>
has not announced when IPv6 will be supported.<BR>
<BR>
4. I *think* my T1 router supports IPv6, but maybe on the next version<BR>
of the software. It's difficult to find the documentation.<BR>
<BR>
5. I don't know if my upstream ISP supports IPv6 yet. Their web site<BR>
does not say. I asked my sales contact that question several weeks ago,<BR>
but between various summer vacations, I haven't gotten an answer yet.<BR>
<BR>
6. Do the software products I use support IPv6 yet?<BR>
<BR>
There is a large amount of inertia here. With what I know at the moment,<BR>
I don't see how we can completely convert the internal network to IPv6<BR>
for at least five years, and maybe longer.<BR>
<BR>
Keith<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
------------------------------<BR>
<BR>
Message: 6<BR>
Date: Wed, 25 Jul 2007 22:39:39 -0400<BR>
From: "William Herrin" <arin-contact@dirtside.com><BR>
Subject: Re: [ppml] Soliciting comments: IPv4 to IPv6 fast migration<BR>
To: "Stephen Sprunk" <stephen@sprunk.org><BR>
Cc: ARIN PPML <ppml@arin.net><BR>
Message-ID:<BR>
<3c3e3fca0707251939p43751536y2c5d9c0bfa77b5b@mail.gmail.com><BR>
Content-Type: text/plain; charset=ISO-8859-1<BR>
<BR>
On 7/25/07, Stephen Sprunk <stephen@sprunk.org> wrote:<BR>
> Thus spake "William Herrin" <arin-contact@dirtside.com><BR>
> > 1. The looming exhaustion of the IPv4 space.<BR>
> > 2. Obsolete and incorrect legacy IPv4 registration and contact<BR>
> > information.<BR>
> > 3. Legacy IPv4 registrants don't pay their fair share.<BR>
> > 4. The need to constrain route announcements in the IPv6 Default-Free<BR>
> > Zone.<BR>
> > <A HREF="http://bill.herrin.us/arin-policy-proposal-6to4.html">http://bill.herrin.us/arin-policy-proposal-6to4.html</A><BR>
><BR>
> I don't see how this proposal solves problems 1 or 4 above, though I'll<BR>
> grant it may partially solve problems 2 and 3.<BR>
<BR>
Hi Stephen,<BR>
<BR>
The only solution I've heard proposed to problem #1 which isn't<BR>
ridiculous is to deploy IPv6. This proposal forwards that goal by<BR>
offering any IPv4 registrant willing to deploy IPv6 now the ability to<BR>
get more IPv6 addresses now than they will qualify for later within<BR>
the scope of a mechanism that allows them to deploy IPv6 themselves<BR>
even if their service provider isn't ready yet. This takes a group of<BR>
folks, IPv4 registrants who don't qualify for IPv6 PI space or just<BR>
aren't paying attention, folks who are now either on the fence or<BR>
actively hostile to IPv6 deployment and converts them enthusiastic<BR>
advocates.<BR>
<BR>
For problem 4, I've had it drilled in to my head that IPv6 PI space<BR>
is a Really Bad Thing because it consumes routing slots in DFZ for<BR>
small organizations of which there are too many. I have mixed emotions<BR>
about that claim but I respect that a substantial number of<BR>
intelligent folks consider it very important. This proposal improves<BR>
that situation by allowing the inevitable PI space to piggy-back on<BR>
the existing IPv4 routing table through what could reasonably be<BR>
described as an MPLS-like tagging process. By doing so, it avoids<BR>
polluting the IPv6 DFZ.<BR>
<BR>
<BR>
> If the goal is to give PIv6 space to legacy holders -- without meeting the<BR>
> existing standard -- in return for subjecting themselves to the RSA and<BR>
> maintenance fees, then I feel that the appropriate place to propose such a<BR>
> change is in the PIv6 policy itself and that such blocks should be assigned<BR>
> from the same superblock that other PIv6 space is assigned from, not from<BR>
> 2002::/16.<BR>
<BR>
That's not the goal. The goal is to ubiquitously deploy IPv6 in the<BR>
next 24 months. For a variety of reasons, that goal is impaired by<BR>
passive hostility from small operators. This proposal forwards the<BR>
goal by converting at least some and hopefully a lot of that hostility<BR>
into productive enthusiasm. Its about using the carrot to lead folks<BR>
to a helpfully fast deployment of IPv6.<BR>
<BR>
And if we can knock out a couple other birds with the same stone, so<BR>
much the better.<BR>
<BR>
Regards,<BR>
Bill Herrin<BR>
<BR>
--<BR>
William D. Herrin herrin@dirtside.com bill@herrin.us<BR>
3005 Crane Dr. Web: <<A HREF="http://bill.herrin.us/">http://bill.herrin.us/</A>><BR>
Falls Church, VA 22042-3004<BR>
<BR>
<BR>
------------------------------<BR>
<BR>
Message: 7<BR>
Date: Wed, 25 Jul 2007 22:40:41 -0400<BR>
From: "William Herrin" <arin-contact@dirtside.com><BR>
Subject: Re: [ppml] Soliciting comments: IPv4 to IPv6 fast migration<BR>
To: "Owen DeLong" <owen@delong.com><BR>
Cc: ppml@arin.net<BR>
Message-ID:<BR>
<3c3e3fca0707251940i70f3b83fpa53782e0312fbf74@mail.gmail.com><BR>
Content-Type: text/plain; charset=ISO-8859-1<BR>
<BR>
On 7/25/07, Owen DeLong <owen@delong.com> wrote:<BR>
> 1. It is very unnecessarily complex.<BR>
<BR>
Hi Owen,<BR>
<BR>
It is complex. I'm open to constuctive suggestions on how to reduce<BR>
that complexity.<BR>
<BR>
<BR>
> 2. Do you really think that the required 6to4 functionality can be<BR>
> widely enough deployed in less than 4 months?<BR>
<BR>
A minimalist implementation involves removing what little filtering of<BR>
2002:: prefixes exists from routers used by some 800 organizations. I<BR>
believe it could be accomplished in 4 weeks, let alone 4 months. All<BR>
the same, this is a fair question for the network operators. I'll<BR>
refer it to the folks on nanog when I ask them.<BR>
<BR>
Beyond the minimalist implementation, orgs are free to filter and<BR>
encapsulate or not, whatever meets their local goals. As no avalanche<BR>
of 6to4 users will suddenly appear on 1/1/2008, they have ample time<BR>
to choose, plan, test and implement.<BR>
<BR>
<BR>
> 3. This would make the 6to4 address range a permanent encampment<BR>
> of legacy v4 holders and preserve all of the issues related to the<BR>
> swamp.<BR>
<BR>
The first issue with the swamp is the scattered, discontiguous blocks.<BR>
This proposal addresses that issue by permitting each org only one<BR>
block.<BR>
<BR>
The second issue with the swamp is ARIN's ambiguous authority to do<BR>
anything about it like asking folks to renumber. This proposal<BR>
addresses that issue by requiring the blocks to fall under the RSA.<BR>
<BR>
This proposal does create a permanent encampment of v4 holders. But<BR>
they're not legacy holders: they'll all have signed an RSA, subjecting<BR>
themselves to then-current IPv4 and IPv6 policies moving forward.<BR>
<BR>
<BR>
> 4. This proposal (and 6to4 in general) appear to ignore what happens<BR>
> when sites have IPv4 addresses, native IPv6 connectivity, but, no<BR>
> longer have native IPv4 connectivity.<BR>
<BR>
Phase 3 of the proposal entitled "Native phase: Following the decline<BR>
of IPv4," addresses your question.<BR>
<BR>
6to4 does not address the question because absent a policy like this<BR>
one the question is moot.<BR>
<BR>
A more general sketch of what happens is this: the backbones drop<BR>
native IPv4 and start tunnelling it before the end-user sites do. The<BR>
end user with 6to4 space certainly isn't going to drop IPv4<BR>
connectivity. As the beckbones drop IPv4, they start routing 2002::<BR>
natively as required in the updated RFC. As a result, a steadily lower<BR>
percentage of the incoming v6 traffic at the end-user site is<BR>
encapsulated. By the time any of this becomes more than a mild<BR>
annoyance, ARIN makes its periodic assessment (last item in phase 2)<BR>
and announces the move to phase 3 in which folks are asked to<BR>
propagate the 2002:: routes so that normal routing takes precendence<BR>
over the 2002::/16 route to the encapsulator while those who are not<BR>
part of the IPv6 DFZ are asked to remove any 6to4 encapsulators.<BR>
<BR>
Regards,<BR>
Bill Herrin<BR>
<BR>
<BR>
--<BR>
William D. Herrin herrin@dirtside.com bill@herrin.us<BR>
3005 Crane Dr. Web: <<A HREF="http://bill.herrin.us/">http://bill.herrin.us/</A>><BR>
Falls Church, VA 22042-3004<BR>
<BR>
<BR>
------------------------------<BR>
<BR>
Message: 8<BR>
Date: Wed, 25 Jul 2007 22:43:22 -0400<BR>
From: "William Herrin" <arin-contact@dirtside.com><BR>
Subject: Re: [ppml] Soliciting comments: IPv4 to IPv6 fast migration<BR>
To: "bill fumerola" <billf@mu.org><BR>
Cc: ARIN Address Policy <ppml@arin.net><BR>
Message-ID:<BR>
<3c3e3fca0707251943r429432at3dfa7d87c63563d2@mail.gmail.com><BR>
Content-Type: text/plain; charset=ISO-8859-1<BR>
<BR>
On 7/25/07, bill fumerola <billf@mu.org> wrote:<BR>
> 6to4 is one of many systems to help transition. changes to how the space<BR>
> is handled must go through the IETF. this policy proposal seems moot<BR>
> given that it seeks to change RFC defined policies.<BR>
<BR>
Hi Bill,<BR>
<BR>
I've been discussing this off-list for the past few weeks with Brian<BR>
Carpenter, one of RFC 3056's authors. The view he expressed to me (and<BR>
I'm relying on his judgement here) is that submitting a short update<BR>
RFC would be a side issue if consensus could be reached here at ARIN<BR>
and among the network operators on NANOG's list. Does that allay your<BR>
concerns about the IETF/RFC side of the proposal?<BR>
<BR>
<BR>
> IETF/RFC concerns aside, dragging legacy addressing assignments forward<BR>
> into a new DFZ we're trying to keep clean also seems counter-productive.<BR>
> turning the 6to4 2002::/16 into a source of potential table pollution<BR>
> seems like the wrong direction to take. this forum is the wrong place<BR>
> to make that decision for the entire community.<BR>
<BR>
It is my intention to ask folks on NANOG's list to comment on the<BR>
operational aspects of the proposal, especially table pollution. I<BR>
wanted to get my feet a little wet over here first before jumping the<BR>
rest of the way in. :)<BR>
<BR>
Regards,<BR>
Bill Herrin<BR>
<BR>
--<BR>
William D. Herrin herrin@dirtside.com bill@herrin.us<BR>
3005 Crane Dr. Web: <<A HREF="http://bill.herrin.us/">http://bill.herrin.us/</A>><BR>
Falls Church, VA 22042-3004<BR>
<BR>
<BR>
------------------------------<BR>
<BR>
Message: 9<BR>
Date: Wed, 25 Jul 2007 21:57:02 -0500<BR>
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es><BR>
Subject: Re: [ppml] Soliciting comments: IPv4 to IPv6 fast migration<BR>
To: <ppml@arin.net><BR>
Message-ID: <C2CD77AE.1A3EDD%jordi.palet@consulintel.es><BR>
Content-Type: text/plain; charset="US-ASCII"<BR>
<BR>
Hi Keith,<BR>
<BR>
This is a very good example of the typical set of issues that have easy<BR>
solutions ;-), at least in a temporary phase, so you can start testing IPv6<BR>
w/o any major investment.<BR>
<BR>
We are talking about transition and co-existence, not migration. Starting<BR>
from that point, all make much more sense. See below in-line.<BR>
<BR>
Regards,<BR>
Jordi<BR>
<BR>
<BR>
<BR>
<BR>
> De: "Keith W. Hare" <Keith@jcc.com><BR>
> Responder a: <ppml-bounces@arin.net><BR>
> Fecha: Wed, 25 Jul 2007 22:36:14 -0400<BR>
> Para: ARIN Address Policy <ppml@arin.net><BR>
> Asunto: Re: [ppml] Soliciting comments: IPv4 to IPv6 fast migration<BR>
><BR>
><BR>
> It is not at all clear to me whether or not this proposal will speed<BR>
> adoption of IPv6.<BR>
><BR>
> I see a several impediments to adopting IPv6:<BR>
><BR>
> 1. Current ARIN policies favor Provider Agregatable (PA) address<BR>
> allocations rather than Provider Independent allocations (PI). Since<BR>
> IPv6 discourages NAT, this suggests that I get an IPv6 address<BR>
<BR>
Doesn't discourages. It is no longer needed, because NAT was created as an<BR>
earlier and quick solution for the lack of IPv4 addresses. Then we started<BR>
using it for many other things that was not designed for (such as avoiding<BR>
renumbering using PA, hiding networks, false security, etc.).<BR>
<BR>
> assignment from an ISP and number all internal resources using the ISP's<BR>
> IPv6 addresses. Then, If I decide to switch ISPs, I have to renumber<BR>
> everything and rewrite all firewall rules. Why would I adopt a protocol<BR>
> that tied me to an ISP?<BR>
<BR>
You can also obtain IPv6 PI if this is problem for your case.<BR>
<BR>
><BR>
> 2. I have lots of devices on the internal network that may not (or<BR>
> maybe they do, I dunno) support IPv6, the temperature monitor and the<BR>
> UPS, for example. These types of devices are going to slow the move to<BR>
> IPv6 in the internal network.<BR>
<BR>
Not an issue, as it is a transition and co-existence, so we keep using<BR>
DUAL-STACK. Those devices still can keep using IPv4. In fact my strong<BR>
recommendation is to keep using dual-stack in the LAN, typically you keep<BR>
using private addresses for IPv4. If any of those devices need to be<BR>
addressed from outside of you LAN, you use same techniques as today (NAT/PAT<BR>
translations, VPNs, etc.), or if you want to use them from IPv6 "only"<BR>
networks, then you will use some kind of portproxy or similar, to allow an<BR>
incoming IPv6 connection to your network to be forwarded to that IPv4 device<BR>
in the LAN.<BR>
<BR>
><BR>
> 3. My firewalls do not currently support IPv6 and the firewall vendor<BR>
> has not announced when IPv6 will be supported.<BR>
<BR>
It is a bad vendor ;-) No, seriously, you can still setup a linux or your<BR>
preferred low-cost alternative box with iptables6.<BR>
<BR>
><BR>
> 4. I *think* my T1 router supports IPv6, but maybe on the next version<BR>
> of the software. It's difficult to find the documentation.<BR>
<BR>
You can use the same box (a PC) to be used as the IPv6 firewall as the IPv6<BR>
router for your network an tunnel IPv6 to outside.<BR>
<BR>
><BR>
> 5. I don't know if my upstream ISP supports IPv6 yet. Their web site<BR>
> does not say. I asked my sales contact that question several weeks ago,<BR>
> but between various summer vacations, I haven't gotten an answer yet.<BR>
<BR>
If your ISP doesn't support IPv6, make sure to ask for it, but meanwhile,<BR>
you can use alternative IPv6 transit providers, most of them even free.<BR>
<BR>
><BR>
> 6. Do the software products I use support IPv6 yet?<BR>
<BR>
Difficult to say w/o a list, but even if it is not the case, as you run<BR>
dual-stack, there is no immediate need for that ! And if needed, portproxy<BR>
is your friend.<BR>
<BR>
><BR>
> There is a large amount of inertia here. With what I know at the moment,<BR>
> I don't see how we can completely convert the internal network to IPv6<BR>
> for at least five years, and maybe longer.<BR>
<BR>
I guess much before 5 years you will have many other reasons to replace<BR>
hardware and apps if you still want to get rid of IPv4 completely at that<BR>
time.<BR>
<BR>
><BR>
> Keith<BR>
><BR>
><BR>
><BR>
><BR>
><BR>
><BR>
><BR>
><BR>
> _______________________________________________<BR>
> This message sent to you through the ARIN Public Policy Mailing List<BR>
> (PPML@arin.net).<BR>
> Manage your mailing list subscription at:<BR>
> <A HREF="http://lists.arin.net/mailman/listinfo/ppml">http://lists.arin.net/mailman/listinfo/ppml</A><BR>
<BR>
<BR>
<BR>
<BR>
------------------------------<BR>
<BR>
_______________________________________________<BR>
PPML mailing list<BR>
PPML@arin.net<BR>
<A HREF="http://lists.arin.net/mailman/listinfo/ppml">http://lists.arin.net/mailman/listinfo/ppml</A><BR>
<BR>
<BR>
End of PPML Digest, Vol 25, Issue 71<BR>
************************************<BR>
</FONT>
</P>
</BODY>
</HTML>