[ppml] Help

Rink, James P CTR USA james.rink at us.army.mil
Wed Jul 25 23:00:04 EDT 2007


--------------------------
Sent from my BlackBerry Wireless Handheld


-----Original Message-----
From: ppml-bounces at arin.net <ppml-bounces at arin.net>
To: ppml at arin.net <ppml at arin.net>
Sent: Wed Jul 25 21:57:26 2007
Subject: PPML Digest, Vol 25, Issue 71

Send PPML mailing list submissions to
	ppml at arin.net

To subscribe or unsubscribe via the World Wide Web, visit
	http://lists.arin.net/mailman/listinfo/ppml
or, via email, send a message with subject or body 'help' to
	ppml-request at arin.net

You can reach the person managing the list at
	ppml-owner at arin.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of PPML digest..."


Today's Topics:

   1. Re: Dean Anderson,	130.105.0.0/16 and the future of the IPv4
      Internet. (Owen DeLong)
   2. Re: Soliciting comments: IPv4 to IPv6 fast migration (Owen DeLong)
   3. Re: EPO (Robert Bonomi)
   4. Re: Dean Anderson, 130.105.0.0/16 and the future of the IPv4
      Internet.] (Dean Anderson)
   5. Re: Soliciting comments: IPv4 to IPv6 fast migration
      (Keith W. Hare)
   6. Re: Soliciting comments: IPv4 to IPv6 fast migration
      (William Herrin)
   7. Re: Soliciting comments: IPv4 to IPv6 fast migration
      (William Herrin)
   8. Re: Soliciting comments: IPv4 to IPv6 fast migration
      (William Herrin)
   9. Re: Soliciting comments: IPv4 to IPv6 fast migration
      (JORDI PALET MARTINEZ)


----------------------------------------------------------------------

Message: 1
Date: Wed, 25 Jul 2007 17:59:28 -0700
From: Owen DeLong <owen at delong.com>
Subject: Re: [ppml] Dean Anderson,	130.105.0.0/16 and the future of
	the IPv4 Internet.
To: Dean Anderson <dean at av8.com>
Cc: Paul Vixie <vixie at vix.com>, ppml at arin.net
Message-ID: <E9271818-C83C-4192-BCE3-A9E46E48B785 at delong.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed

Actually, it is not.  There is a process for addressing that documented
on the ARIN website and nowhere does it suggest posting such an
accusation to the PPML.

http://www.arin.net/about_us/boardguidelines.html#removal

So, Dean, I suggest you go try and recruit either 10% of the members in
good standing or a majority of the BoT  to make an appropriate petition
or motion.

Owen

On Jul 25, 2007, at 3:16 PM, Dean Anderson wrote:

> Its not the right forum to discuss the details of Vixie and crony
> finances.
>
> But, I believe this is the right forum for discussing the details of
> ARIN Board Member misconduct, and its relation to false claims about
> 130.105/16 being hijacked/disused.
>
> 		--Dean
>
>
> On Wed, 25 Jul 2007, David Williamson wrote:
>
>> On Wed, Jul 25, 2007 at 01:27:54PM -0400, Dean Anderson wrote:
>>> While this isn't really the right forum,
>>
>> That's absolutely correct.  Please please PLEASE take this somewhere
>> else.  This has zero to do with ARIN policy.
>>
>> -David
>>
>>
>
> -- 
> Av8 Internet   Prepared to pay a premium for better service?
> www.av8.net         faster, more reliable, better service
> 617 344 9000
>
>
> _______________________________________________
> This message sent to you through the ARIN Public Policy Mailing List
> (PPML at arin.net).
> Manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml



------------------------------

Message: 2
Date: Wed, 25 Jul 2007 18:07:51 -0700
From: Owen DeLong <owen at delong.com>
Subject: Re: [ppml] Soliciting comments: IPv4 to IPv6 fast migration
To: "William Herrin" <arin-contact at dirtside.com>
Cc: ARIN Address Policy <ppml at arin.net>
Message-ID: <77053E98-C998-4094-8970-C6213947B4A6 at delong.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed

I have some comments on the proposal as follows:

1.	It is very unnecessarily complex.
2.	Do you really think that the required 6to4 functionality can be
	widely enough deployed in less than 4 months?
3.	This would make the 6to4 address range a permanent encampment
	of legacy v4 holders and preserve all of the issues related to the  
swamp.
	We should not give up on the v6 transition as an opportunity to  
drain the
	swamp.  Enshrining the swamp in a permanent IPv6 map is
	counter-productive.
4.	This proposal (and 6to4 in general) appear to ignore what happens
	when sites have IPv4 addresses, native IPv6 connectivity, but, no
	longer have native IPv4 connectivity.

I oppose the proposal as written.

Owen



------------------------------

Message: 3
Date: Wed, 25 Jul 2007 20:44:15 -0500 (CDT)
From: Robert Bonomi <bonomi at mail.r-bonomi.com>
Subject: Re: [ppml] EPO
To: ppml at arin.net
Message-ID: <200707260144.l6Q1iFbI005782 at s25.firmware.com>

> From owner-nanog at merit.edu  Wed Jul 25 15:53:45 2007
> Date: Wed, 25 Jul 2007 12:10:11 -0700
> To: nanog at merit.edu
>
>
> Leo Bicknell wrote:
> > I was complaining to some of the power designers during the building
> > of a major facility that the EPO button represented a single point
> > of failure, and effectively made all of the redundancy built into
> > the power system useless.  After all, what's the point of having
> > two (or more) of anything, if there's one button somewhere that
> > turns it all off?
>

It seems to me -- without digging into 'code' compliance reqirements -- that
one could profit from some of the 'positive control' designs used in 
missle silos, nuclear submarines, and the like.

Where, to trigger the function, *two* 'buttons' must be pushed.  And the
buttons are located such that a single person cannot reach both simultaneously.

Requiring '2 of 2' buttons to trigger eliminates false positives, but 
doubles the risk of 'false negatives' if a button malfunctions.  This
issue can be ameliorated by providing 'more than 2' buttons, while requiring
only two buttons pushed to trigger.  '2 of 3' will work properly unless there 
is a _double_ failure -- intentional or accidental.

Particularly for a building-wide 'kill' switch, this would seem to be a
prudent design.

A passive design turns out to be fairly simple. Requirements, in minimal form
is a DPDT swith in each  box, and 3-wire daisy-chain interconnect.
Use 'ring' wiring, with both ends tied to the master control, and even a
break (single) in the wiring does not a failure make.




------------------------------

Message: 4
Date: Wed, 25 Jul 2007 22:34:46 -0400 (EDT)
From: Dean Anderson <dean at av8.com>
Subject: Re: [ppml] Dean Anderson, 130.105.0.0/16 and the future of
	the IPv4 Internet.]
To: Paul Vixie <paul at vix.com>
Cc: ppml at arin.net
Message-ID:
	<Pine.LNX.4.44.0707252227080.20640-100000 at citation2.av8.net>
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Thu, 26 Jul 2007, Paul Vixie wrote:

> we will never know if dean actually believes that the UN is going to
> take over the governance of the united states of america, or if he
> just says that kind of stuff to amuse us or to amuse himself.

I've never said that the UN is going to take over the governance of the
United States of America.  I said it was possible that the UN might take
over the governance of the Internet, from the US Department of Commerce.

One might otherwise be tempted to add "...Idiot", but your departure
from reality is truly extraordinary.

But as we've seen that you repeatedly make entirely false statements,
I'm not too surprised by this last one. However, your pathological lying
is unbecoming and worrisome when it comes from a person entrusted with
the serious responsibilities of which you are entrusted.

		--Dean



-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000   




------------------------------

Message: 5
Date: Wed, 25 Jul 2007 22:36:14 -0400
From: "Keith W. Hare" <Keith at jcc.com>
Subject: Re: [ppml] Soliciting comments: IPv4 to IPv6 fast migration
To: "ARIN Address Policy" <ppml at arin.net>
Message-ID: <5c1a7aa646c813405eb2285b353cccd546a808ad at jcc.com>
Content-Type: text/plain;	charset="us-ascii"


It is not at all clear to me whether or not this proposal will speed
adoption of IPv6.

I see a several impediments to adopting IPv6:

1. Current ARIN policies favor Provider Agregatable (PA) address
allocations rather than Provider Independent allocations (PI).  Since
IPv6 discourages NAT, this suggests that I get an IPv6 address
assignment from an ISP and number all internal resources using the ISP's
IPv6 addresses.  Then, If I decide to switch ISPs, I have to renumber
everything and rewrite all firewall rules.  Why would I adopt a protocol
that tied me to an ISP?  

2.  I have lots of devices on the internal network that may not (or
maybe they do, I dunno) support IPv6, the temperature monitor and the
UPS, for example.  These types of devices are going to slow the move to
IPv6 in the internal network.

3.  My firewalls do not currently support IPv6 and the firewall vendor
has not announced when IPv6 will be supported.

4.  I *think* my T1 router supports IPv6, but maybe on the next version
of the software.  It's difficult to find the documentation.

5.  I don't know if my upstream ISP supports IPv6 yet.  Their web site
does not say.  I asked my sales contact that question several weeks ago,
but between various summer vacations, I haven't gotten an answer yet.

6. Do the software products I use support IPv6 yet?

There is a large amount of inertia here. With what I know at the moment,
I don't see how we can completely convert the internal network to IPv6
for at least five years, and maybe longer.

Keith










------------------------------

Message: 6
Date: Wed, 25 Jul 2007 22:39:39 -0400
From: "William Herrin" <arin-contact at dirtside.com>
Subject: Re: [ppml] Soliciting comments: IPv4 to IPv6 fast migration
To: "Stephen Sprunk" <stephen at sprunk.org>
Cc: ARIN PPML <ppml at arin.net>
Message-ID:
	<3c3e3fca0707251939p43751536y2c5d9c0bfa77b5b at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

On 7/25/07, Stephen Sprunk <stephen at sprunk.org> wrote:
> Thus spake "William Herrin" <arin-contact at dirtside.com>
> > 1. The looming exhaustion of the IPv4 space.
> > 2. Obsolete and incorrect legacy IPv4 registration and contact
> > information.
> > 3. Legacy IPv4 registrants don't pay their fair share.
> > 4. The need to constrain route announcements in the IPv6 Default-Free
> > Zone.
> > http://bill.herrin.us/arin-policy-proposal-6to4.html
>
> I don't see how this proposal solves problems 1 or 4 above, though I'll
> grant it may partially solve problems 2 and 3.

Hi Stephen,

  The only solution I've heard proposed to problem #1 which isn't
ridiculous is to deploy IPv6. This proposal forwards that goal by
offering any IPv4 registrant willing to deploy IPv6 now the ability to
get more IPv6 addresses now than they will qualify for later within
the scope of a mechanism that allows them to deploy IPv6 themselves
even if their service provider isn't ready yet. This takes a group of
folks, IPv4 registrants who don't qualify for IPv6 PI space or just
aren't paying attention, folks who are now either on the fence or
actively hostile to IPv6 deployment and converts them enthusiastic
advocates.

  For problem 4, I've had it drilled in to my head that IPv6 PI space
is a Really Bad Thing because it consumes routing slots in DFZ for
small organizations of which there are too many. I have mixed emotions
about that claim but I respect that a substantial number of
intelligent folks consider it very important. This proposal improves
that situation by allowing the inevitable PI space to piggy-back on
the existing IPv4 routing table through what could reasonably be
described as an MPLS-like tagging process. By doing so, it avoids
polluting the IPv6 DFZ.


> If the goal is to give PIv6 space to legacy holders -- without meeting the
> existing standard -- in return for subjecting themselves to the RSA and
> maintenance fees, then I feel that the appropriate place to propose such a
> change is in the PIv6 policy itself and that such blocks should be assigned
> from the same superblock that other PIv6 space is assigned from, not from
> 2002::/16.

That's not the goal. The goal is to ubiquitously deploy IPv6 in the
next 24 months. For a variety of reasons, that goal is impaired by
passive hostility from small operators. This proposal forwards the
goal by converting at least some and hopefully a lot of that hostility
into productive enthusiasm. Its about using the carrot to lead folks
to a helpfully fast deployment of IPv6.

And if we can knock out a couple other birds with the same stone, so
much the better.

Regards,
Bill Herrin

-- 
William D. Herrin                  herrin at dirtside.com  bill at herrin.us
3005 Crane Dr.                        Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


------------------------------

Message: 7
Date: Wed, 25 Jul 2007 22:40:41 -0400
From: "William Herrin" <arin-contact at dirtside.com>
Subject: Re: [ppml] Soliciting comments: IPv4 to IPv6 fast migration
To: "Owen DeLong" <owen at delong.com>
Cc: ppml at arin.net
Message-ID:
	<3c3e3fca0707251940i70f3b83fpa53782e0312fbf74 at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

On 7/25/07, Owen DeLong <owen at delong.com> wrote:
> 1.      It is very unnecessarily complex.

Hi Owen,

It is complex. I'm open to constuctive suggestions on how to reduce
that complexity.


> 2.      Do you really think that the required 6to4 functionality can be
>         widely enough deployed in less than 4 months?

A minimalist implementation involves removing what little filtering of
2002:: prefixes exists from routers used by some 800 organizations. I
believe it could be accomplished in 4 weeks, let alone 4 months. All
the same, this is a fair question for the network operators. I'll
refer it to the folks on nanog when I ask them.

Beyond the minimalist implementation, orgs are free to filter and
encapsulate or not, whatever meets their local goals. As no avalanche
of 6to4 users will suddenly appear on 1/1/2008, they have ample time
to choose, plan, test and implement.


> 3.      This would make the 6to4 address range a permanent encampment
>         of legacy v4 holders and preserve all of the issues related to the
>         swamp.

The first issue with the swamp is the scattered, discontiguous blocks.
This proposal addresses that issue by permitting each org only one
block.

The second issue with the swamp is ARIN's ambiguous authority to do
anything about it like asking folks to renumber. This proposal
addresses that issue by requiring the blocks to fall under the RSA.

This proposal does create a permanent encampment of v4 holders. But
they're not legacy holders: they'll all have signed an RSA, subjecting
themselves to then-current IPv4 and IPv6 policies moving forward.


> 4.      This proposal (and 6to4 in general) appear to ignore what happens
>         when sites have IPv4 addresses, native IPv6 connectivity, but, no
>         longer have native IPv4 connectivity.

Phase 3 of the proposal entitled "Native phase: Following the decline
of IPv4," addresses your question.

6to4 does not address the question because absent a policy like this
one the question is moot.

A more general sketch of what happens is this: the backbones drop
native IPv4 and start tunnelling it before the end-user sites do. The
end user with 6to4 space certainly isn't going to drop IPv4
connectivity. As the beckbones drop IPv4, they start routing 2002::
natively as required in the updated RFC. As a result, a steadily lower
percentage of the incoming v6 traffic at the end-user site is
encapsulated. By the time any of this becomes more than a mild
annoyance, ARIN makes its periodic assessment (last item in phase 2)
and announces the move to phase 3 in which folks are asked to
propagate the 2002:: routes so that normal routing takes precendence
over the 2002::/16 route to the encapsulator while those who are not
part of the IPv6 DFZ are asked to remove any 6to4 encapsulators.

Regards,
Bill Herrin


-- 
William D. Herrin                  herrin at dirtside.com  bill at herrin.us
3005 Crane Dr.                        Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


------------------------------

Message: 8
Date: Wed, 25 Jul 2007 22:43:22 -0400
From: "William Herrin" <arin-contact at dirtside.com>
Subject: Re: [ppml] Soliciting comments: IPv4 to IPv6 fast migration
To: "bill fumerola" <billf at mu.org>
Cc: ARIN Address Policy <ppml at arin.net>
Message-ID:
	<3c3e3fca0707251943r429432at3dfa7d87c63563d2 at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

On 7/25/07, bill fumerola <billf at mu.org> wrote:
> 6to4 is one of many systems to help transition. changes to how the space
> is handled must go through the IETF. this policy proposal seems moot
> given that it seeks to change RFC defined policies.

Hi Bill,

I've been discussing this off-list for the past few weeks with Brian
Carpenter, one of RFC 3056's authors. The view he expressed to me (and
I'm relying on his judgement here) is that submitting a short update
RFC would be a side issue if consensus could be reached here at ARIN
and among the network operators on NANOG's list. Does that allay your
concerns about the IETF/RFC side of the proposal?


> IETF/RFC concerns aside, dragging legacy addressing assignments forward
> into a new DFZ we're trying to keep clean also seems counter-productive.
> turning the 6to4 2002::/16 into a source of potential table pollution
> seems like the wrong direction to take. this forum is the wrong place
> to make that decision for the entire community.

It is my intention to ask folks on NANOG's list to comment on the
operational aspects of the proposal, especially table pollution. I
wanted to get my feet a little wet over here first before jumping the
rest of the way in. :)

Regards,
Bill Herrin

-- 
William D. Herrin                  herrin at dirtside.com  bill at herrin.us
3005 Crane Dr.                        Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


------------------------------

Message: 9
Date: Wed, 25 Jul 2007 21:57:02 -0500
From: JORDI PALET MARTINEZ <jordi.palet at consulintel.es>
Subject: Re: [ppml] Soliciting comments: IPv4 to IPv6 fast migration
To: <ppml at arin.net>
Message-ID: <C2CD77AE.1A3EDD%jordi.palet at consulintel.es>
Content-Type: text/plain;	charset="US-ASCII"

Hi Keith,

This is a very good example of the typical set of issues that have easy
solutions ;-), at least in a temporary phase, so you can start testing IPv6
w/o any major investment.

We are talking about transition and co-existence, not migration. Starting
from that point, all make much more sense. See below in-line.

Regards,
Jordi




> De: "Keith W. Hare" <Keith at jcc.com>
> Responder a: <ppml-bounces at arin.net>
> Fecha: Wed, 25 Jul 2007 22:36:14 -0400
> Para: ARIN Address Policy <ppml at arin.net>
> Asunto: Re: [ppml] Soliciting comments: IPv4 to IPv6 fast migration
> 
> 
> It is not at all clear to me whether or not this proposal will speed
> adoption of IPv6.
> 
> I see a several impediments to adopting IPv6:
> 
> 1. Current ARIN policies favor Provider Agregatable (PA) address
> allocations rather than Provider Independent allocations (PI).  Since
> IPv6 discourages NAT, this suggests that I get an IPv6 address

Doesn't discourages. It is no longer needed, because NAT was created as an
earlier and quick solution for the lack of IPv4 addresses. Then we started
using it for many other things that was not designed for (such as avoiding
renumbering using PA, hiding networks, false security, etc.).

> assignment from an ISP and number all internal resources using the ISP's
> IPv6 addresses.  Then, If I decide to switch ISPs, I have to renumber
> everything and rewrite all firewall rules.  Why would I adopt a protocol
> that tied me to an ISP?

You can also obtain IPv6 PI if this is problem for your case.

> 
> 2.  I have lots of devices on the internal network that may not (or
> maybe they do, I dunno) support IPv6, the temperature monitor and the
> UPS, for example.  These types of devices are going to slow the move to
> IPv6 in the internal network.

Not an issue, as it is a transition and co-existence, so we keep using
DUAL-STACK. Those devices still can keep using IPv4. In fact my strong
recommendation is to keep using dual-stack in the LAN, typically you keep
using private addresses for IPv4. If any of those devices need to be
addressed from outside of you LAN, you use same techniques as today (NAT/PAT
translations, VPNs, etc.), or if you want to use them from IPv6 "only"
networks, then you will use some kind of portproxy or similar, to allow an
incoming IPv6 connection to your network to be forwarded to that IPv4 device
in the LAN.

> 
> 3.  My firewalls do not currently support IPv6 and the firewall vendor
> has not announced when IPv6 will be supported.

It is a bad vendor ;-) No, seriously, you can still setup a linux or your
preferred low-cost alternative box with iptables6.

> 
> 4.  I *think* my T1 router supports IPv6, but maybe on the next version
> of the software.  It's difficult to find the documentation.

You can use the same box (a PC) to be used as the IPv6 firewall as the IPv6
router for your network an tunnel IPv6 to outside.

> 
> 5.  I don't know if my upstream ISP supports IPv6 yet.  Their web site
> does not say.  I asked my sales contact that question several weeks ago,
> but between various summer vacations, I haven't gotten an answer yet.

If your ISP doesn't support IPv6, make sure to ask for it, but meanwhile,
you can use alternative IPv6 transit providers, most of them even free.

> 
> 6. Do the software products I use support IPv6 yet?

Difficult to say w/o a list, but even if it is not the case, as you run
dual-stack, there is no immediate need for that ! And if needed, portproxy
is your friend.

> 
> There is a large amount of inertia here. With what I know at the moment,
> I don't see how we can completely convert the internal network to IPv6
> for at least five years, and maybe longer.

I guess much before 5 years you will have many other reasons to replace
hardware and apps if you still want to get rid of IPv4 completely at that
time.

> 
> Keith
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> This message sent to you through the ARIN Public Policy Mailing List
> (PPML at arin.net).
> Manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml




------------------------------

_______________________________________________
PPML mailing list
PPML at arin.net
http://lists.arin.net/mailman/listinfo/ppml


End of PPML Digest, Vol 25, Issue 71
************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20070725/06315032/attachment.htm>


More information about the ARIN-PPML mailing list