From pesherb at yahoo.com  Mon Jul  3 08:32:04 2006
From: pesherb at yahoo.com (Peter Sherbin)
Date: Mon, 3 Jul 2006 05:32:04 -0700 (PDT)
Subject: [ppml] "Recommended Practices" procedure
In-Reply-To: <1c16a4870606301543m64171de6r3d2e03cc594f45ab@mail.gmail.com>
Message-ID: <20060703123204.26468.qmail@web54707.mail.yahoo.com>

> We on this list are savvy enough to understand the value of PI space,
> but many downstream customers are not.

Tell those unsure that with PI they get a complete control over their network which
they hardly ever will need to re-number.

Thanks,

Peter


--- Stacy Taylor <ipgoddess at gmail.com> wrote:

> Hi Everyone,
> Caveat:  This evidence is purely anecdotal.
> 
> I likewise have this experience.  While I do my best to change the
> perceptions of my customers regarding ARIN, many persist that the
> registry is a monolith to be avoided.  They know me, they trust me,
> they want my IP space.
> We on this list are savvy enough to understand the value of PI space,
> but many downstream customers are not.
> 
> Thanks,
> /Stacy
> 
> 
> On 6/30/06, Kevin Loch <kloch at hotnic.net> wrote:
> > Azinger, Marla wrote:
> > > Yes, I get what you are saying.  The fact being overlooked
> > > here is that no matter how it boils down, I have customers that
> > > do not want PI space.  I understand that there are some enterprises
> > > that think PI space is their dream answer.  But not everyone has the same
> dream.
> >
> > I'm having a hard time imagining someone who needs to multihome badly
> > but will not accept PI space even if they qualify for it.
> >
> > Can you give an example of the type of customer that would be
> > in that situation?
> >
> > - Kevin
> > _______________________________________________
> > PPML mailing list
> > PPML at arin.net
> > http://lists.arin.net/mailman/listinfo/ppml
> >
> _______________________________________________
> PPML mailing list
> PPML at arin.net
> http://lists.arin.net/mailman/listinfo/ppml
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From william at elan.net  Wed Jul  5 03:04:56 2006
From: william at elan.net (william(at)elan.net)
Date: Wed, 5 Jul 2006 00:04:56 -0700 (PDT)
Subject: [ppml] FYI - ARIN in court for refusing to transfer ip block
Message-ID: <Pine.LNX.4.62.0607041032310.2080@sokol.elan.net>


Visiting internetgovernance.org site for unrelated reasons, I found
copy of the following legal action against ARIN:
   http://internetgovernance.org/pdf/kremen.pdf

The lawsuit is from Gary Kremen (the guy who originally registered
sex.com and from who it was stolen by M. Cohen) and is due to ARIN 
refusal to do a transfer (of blocks & ASNs previously used by Cohen).
My impression is that they are talking about legacy ip space (probably
/16, possibly more then one) although actual ip blocks are not directly 
mentioned. Of note is that Mr. Kremen (or his attorney) somehow thinks
that ip blocks can be sold as a property (page 8: "The enhanced value
of large NETBLOCKS is reflected in the marketplace, in that NETBLOCKS
are bought, sold, and licensed like other valuable property or resources; 
NETBLOCK holdings are factored into the valuations of both public and
private companies worldwide").

In any case those interested should really just read it for yourself
(its not as cumbersome as other similar-type docs I've seen) and those
on AC and BoT are even mentioned as kind-of co-conspirators. And perhaps
in the future meeting ARIN legal council should consider making public
statement about this and explaining ARIN's position.

-- 
William Leibzon
Elan Networks
william at elan.net


From Michael.Dillon at btradianz.com  Wed Jul  5 06:22:40 2006
From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com)
Date: Wed, 5 Jul 2006 11:22:40 +0100
Subject: [ppml] v6 multihoming and route filters
In-Reply-To: <200606302127.k5ULRvc7006227@tislabs.com>
Message-ID: <OFAB2C7365.3BF50E2D-ON802571A2.0038BF57-802571A2.0039024A@btradianz.com>

> What is certainly not artificial is that the capacity of the router
> platforms must be sufficient to handle the largest routing table they
> might carry.  That depends on the routing architecture design,
> certainly. 

Not so.

ISPs make business and technical decisions which determine
how many routes they carry. It is not imposed top-down
by the routing architecture. This is an important 
feature for scalability since it means that individual
ISPs can take action without waiting for some committee
to fix the routing architecture.

--Michael Dillon




From memsvcs at arin.net  Thu Jul 13 11:59:04 2006
From: memsvcs at arin.net (Member Services)
Date: Thu, 13 Jul 2006 11:59:04 -0400
Subject: [ppml] Deadline for Policy Proposals - 12 August 2006
Message-ID: <44B66DC8.3060709@arin.net>

The ARIN XVIII Public Policy Meeting will take place 11-12 October 2006
in St. Louis. New policy proposals must be submitted by 23:59 EDT, 12
August 2006, in order to be considered by the ARIN Advisory Council for
possible inclusion on the ARIN XVIII agenda. This is in accordance with
ARIN's Internet Resource Policy Evaluation Process, which requires that
proposed policies be submitted at least 60 days prior to the meeting.

Those who wish to propose new ARIN number resource policies or
modifications to existing policies must submit a Policy Proposal
Template. The template must be sent via e-mail to policy at arin.net.

The Policy Proposal Template can be found at:
http://www.arin.net/policy/irpep_template.html

The ARIN Internet Resource Policy Evaluation Process can be found at:
http://www.arin.net/policy/irpep.html

Regards,

Member Services
American Registry for Internet Numbers (ARIN)



From memsvcs at arin.net  Tue Jul 18 15:47:57 2006
From: memsvcs at arin.net (Member Services)
Date: Tue, 18 Jul 2006 15:47:57 -0400
Subject: [ppml] Policy Proposal 2006-2: Micro-allocations for Internal
 Infrastructure - revised text
Message-ID: <44BD3AED.9050300@arin.net>

Policy Proposal 2006-2: Micro-allocations for Internal Infrastructure
has been revised. This proposal is open for discussion on this mailing
list and will be on the agenda at the upcoming ARIN Public Policy Meeting.

The current policy proposal text is provided below and is also available
at: http://www.arin.net/policy/proposals/2006_2.html

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


### * ###


Policy Proposal 2006-2: Micro-allocations for Internal Infrastructure

Proposal type: modify

Policy term: permanent

Policy statement:

6.10.1 Micro-allocations for Internal Infrastructure

Organizations that currently hold IPv6 allocations may apply for a
micro-allocation for internal infrastructure. Applicant must provide
technical justification indicating why a separate non-routed block is
required. Justification must include why a sub-allocation of currently
held IP space cannot be utilized. Internal infrastructure allocations
must be allocated from specific blocks reserved only for this purpose.


Rationale:

Organizations that have only a single aggregate may require
additional noncontiguous IP space for their internal infrastructure.
This space should not be routed in the global Internet routing table.
This will provide for the protection of internal infrastructure and
support for applications that are sensitive to long convergence times
like VoIP.

It is important to note that the additional prefix allocation will not
negatively impact the global routing table size as the additional prefix
should not be routed.

BGP Re-Convergence
------------------

ISPs use BGP to originate their aggregate from multiple nodes within
their infrastructure.  They do this by routing their aggregate to
discard on multiple devices. This ensures the Internet can reach the
aggregate even when one or more nodes fail.

If the next hop for a route is reachable via an aggregate that is in the
routing table, then failures affecting the reachability of the next hop
are subject to BGP hold timers, which can cause traffic to be dropped
for the length of the bgp hold time

(typically 3 minutes)

The BGP re-convergence problem results when a multi-homed customer is
announcing the same route to two different edge routers.  When the edge
router sourcing the primary path fails, the local address which is
acting as the next hop, is removed from the IGP.  If the next hop is
still reachable through an aggregate or covering route, then the route
will not be immediately invalidated in bgp.  Until the bgp session with
the failed device times out, traffic will be drawn to the device
originating the aggregate, which is routed to discard and traffic will
be dropped.  After the bgp session with the failed device times out, the
route will be removed and the next best route will be used.  To minimize
route failover time, you must ensure that the local addresses of the
infrastructure, that act as next-hops for Internet routes, are NOT
numbered with addresses that are a more specific than the aggregate.

A detailed description of the problem space follows in the next three
paragraphs.

Having BGP next-hops that are not aggregated can cause faster
convergence for customers who have multiple links to multiple routers of
a single upstream AS.
Take the case where a customer has two connections, link1 to
edge-router1 and link2 to edge-router2, to a single upstream AS. The
customer has an eBGP session with the loopback 2001:DB8::1/128 on
edge-router1 and with loopback 2001:DB8::2/128 on edge-router2.  The
customer advertises a single prefix 2001:DB8:1000::/48 to both
edge-router1 and edge-router2.  The edge routers set next-hop self.  The
upstream ISP will have two paths to the prefix 2001:DB8:1000::/48, one
with a protocol next-hop of 2001:DB8::1 and one with a protocol next-hop
of 2001:DB8::2.  Assume the upstream ISP's entire network prefers the
path to 2001:DB8:1000::/48 with a protocol next-hop of 2001:DB8::1 due
to lower BGP MED value.  Also assume that all of the address space owned
by the upstream ISP is 2001:DB8::/32, and the loopbacks of both edge
routers are a more specific of the aggregate /32.  The upstream ISP has
a pull-up route for 2001:DB8::/32 in the core of the network.  This
allows for the aggregation of all the more specific routes of
2001:DB8::/32.  It insures the stability of the 2001:DB8::/32
announcement, while preventing an isolated edge router from advertising
reachability to the network.

If edge-router1 fails then 2001:DB8::1/128 will be immediately removed
from the IGP.  The preferred prefix for 2001:DB8:1000::/48 with a
next-hop of 2001:DB8::1 will remain a valid bgp route and will continue
to be the best path because 2001:DB8::1 is reachable through the pull-up
route 2001:DB8::/32.  Traffic will get blackholed for up to three
minutes (BGP default hold time) until the BGP prefix 2001:DB8:1000::/48
with a protocol next-hop of 2001:DB8::1 times out.  Only then will
traffic get forwarded to the next best path for 2001:DB8:1000::/48 with
a protocol next-hop of 2001:DB8::2.

If instead the loopbacks of the edge routers (or any BGP protocol
next-hop addresses) are not part of the 2001:DB8::/32 aggregate, and
there is no aggregate that covers the edge router loopbacks, then
convergence will be much quicker.  Assume that edge-router1 is using
2001:408::1 and edge-router2 is using 2001:408::2, and the only pull-up
route is 2001:DB8::/32.  In this case once edge-router1 fails, the IGP
will detect it and remove 2001:408::1/128 from the IGP.  This will
invalidate the preferred path to 201:DB8:1000::/48 with a protocol
next-hop of 2001:408:1 as there will be no route to the next hop (or
even a less specific of this address).  Once the path is invalidated,
then the next best path to 2001:DB8:1000::/48 with a protocol next-hop
of  2001:408::2 will be declared best.  Convergence times will be on the
order of magnitude of the IGP failure detection and path re-calculation,
typically less than one second.


                      ---------------
                      | Core Router |static route
                      |             |2001:DB8::/32 discard
                      ----+------+---
                          |      |
                          /       \
           /-------------/         \--------\
          /                                  \
         /  /----------------------------\    \
         |  |                             |   |
------+---+--                         --+---+------
|Core Router|static route             |Core Router|static route
|           |2001:DB8::/32 discard    |           |2001:DB8::/32 discard
---------+---                         ---------+---
          |                                     |
---------+---------                   ---------+---------
|  edge-router1   |                   |  edge-router2   |
| 2001:DB8::1/128 |                   | 2001:DB8::2/128 |
---------+---------                   ---------+---------
          |                                     |
           \    link1                  link2    /
            \------------\           /----------/
                          \         /
                          |         |
                      ----+---------+----
                      |      CPE        |
                      |                 |
                      ---------+---------
                               |
                     LAN 2001:DB8:1000::/48


Internal Infrastructure Security Considerations
-----------------------------------------------

Internal infrastructure could be numbered out of space that is not
routed or reachable by the public Internet.  This could be used to
secure internal only services in a multi-layered approach by filtering
direct network connections in the forwarding plane, and not routing the
network in the global Internet routing table.  Internal services which
could take advantage of these layers of protection include: SNMP
services, iBGP mesh, Out-of-Band management network(s), remote access to
the network devices that make up the network in question. A layered
security approach will help to prevent breaches in security via singular
config management problems. Additionally, having all of the services out
of an aggregate block will simplify the configuration management situation.

In essence, this allows for a two tier approach of protecting
infrastructure, both in the control plane by not routing the network,
and in the forwarding plane by utilizing packet filters which are easily
constructed and managed due to the uniqueness of the internal
infrastructure block.

Private Address Considerations
------------------------------

Private addresses are not appropriate for a number of reasons.  A public
Internet network using private addresses internally may create confusion
if trace routes contain private addresses.  Additional problems may
result due to wide spread filtering of private address space.  ICMP
messages may get dropped due to such a policy.  This can lead to
perceived odd behavior and make troubleshooting difficult.

Additionally, the consequences of accidentally routing private ip space
that is not globally unique, are potentially worse than if you
accidentally announced globally unique space.

DNS for private address space is today provided by blackhole-1.iana.org.
and blackhole-2.iana.org. A provider who wants to maintain forward and
reverse DNS sanity has to hijack those ip addresses to provide
consistent DNS resolution.
This will cause any users who's traffic transits that provider's network
to also get 'inconsistent' answers with respect to the private address
space in question.

For management and troubleshooting purposes, it is important that
infrastructure which provides Internet route reachability be numbered
with addresses that resolve through DNS.  Also, global uniqueness of
addressing is important in minimizing renumbering efforts as
organizations (and their networks) merge.  RFC 4193 provides for neither
of these needs.

Timetable for implementation: Immediate






From dianeshuman at mindspring.com  Wed Jul 19 18:35:05 2006
From: dianeshuman at mindspring.com (Diane Shuman)
Date: Wed, 19 Jul 2006 18:35:05 -0400
Subject: [ppml] (no subject)
Message-ID: <410-22006731922355957@mindspring.com>




dianeshuman at mindspring.com
EarthLink Revolves Around You.





From memsvcs at arin.net  Mon Jul 31 17:24:47 2006
From: memsvcs at arin.net (Member Services)
Date: Mon, 31 Jul 2006 17:24:47 -0400
Subject: [ppml] Statement on the Registration Services Agreement
Message-ID: <007901c6b4e7$bf8c3600$5f8888c0@arin.net>

A document that provides information regarding the ARIN Registration Service Agreement (RSA) and the manner in which its content is managed can be found at http://www.arin.net/registration/agreements/rsa_comments.pdf.

Raymond A. Plzak
President and CEO
American Registry for Internet Numbers