[ppml] a modified proposal 2005-8

Davis, Terry L terry.l.davis at boeing.com
Thu Mar 16 18:00:23 EST 2006


Robert

Obviously someone who has at least been around utility companies.  Good
responses.

I think we will find a lot of industries that need their own separate
networks as we grow the Internet.

Take care
Terry

-----Original Message-----
From: Robert Bonomi [mailto:bonomi at mail.r-bonomi.com] 
Sent: Thursday, March 16, 2006 2:04 PM
To: ppml at arin.net
Subject: Re: [ppml] a modified proposal 2005-8

> Date: Thu, 16 Mar 2006 16:45:01 -0500
> From: "Howard, W. Lee" <Lee.Howard at stanleyassociates.com>
> Subject: Re: [ppml] a modified proposal 2005-8
>
> > -----Original Message-----
> > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On 
> > Behalf Of Davis, Terry L
> > Sent: Wednesday, March 15, 2006 10:29 PM
> > To: Houle, Joseph D (Joe), CMO
> > Cc: ppml at arin.net; bookeym at pachenalight.com
> > Subject: Re: [ppml] a modified proposal 2005-8
> > 
> > Joe
> > 
> > Nope, you read it correctly!
> > 
> > The power company will require your electrical systems to be on
their
> > PLC networks in order to control your electrical systems; it 
> > would make
> > a completely unworkable control and routing system for the electric
> > company to try to map the homeowners ISP assigned networks to 
> > your home load controller.
>
> Why?  They have to have a table mapping (IP) address to (home)
address,
> so why does it matter if the IP address is theirs?

The anser to that has to do with "O'Brien's Law".  Which states rather
pithily: "Murphy was an _optimist_!"

Why the 'mapping table' approach won't work on the public IP network:

*dynamic* IP addresses assigned by ISPs are subject to change at any
time,
without notice.  <grin>

IF the ISP changes your address, the utility 'mapping table' is
obselete.

Or, how about an ISP that uses RFC-1918 space internally, w/ NAT/PAT for
that traffic that goes 'off net' to an external network?  Every 'SYN' 
packet from your machine may have a _different_ source IP address at the
destination.  *WHICH* address should be in  the  'mapping table'.


If the utility does query/polling of your load controllers, you're
running
*servers*.  this complicates ISP network architecture considerably.

The utility has *GOOD* reasons to run a 'private' -- *not* connected to
the
public Internet for power-control functions.  Contemplate what could
happen
if a hacker started 'spoofing' directives from the power company  --
whether
it be to 'shut down all equipment immediately', or to 'run everything at

full power'.

> > You will need to interface to their control center somehow to set
your
> > home systems/load controllers and that could be via any available
> > networks but the actual controls will need to come in over their
> > networks.
>
> I'm trying to understand your position:  The power company needs to
> build its own IP network in order to manage power systems at each
> home; their IP address assignments will be from their aggregatable
> block.

*Yes*, they need their own _isolated_ network.
_NO_, the IP address assignments on that network do not need to be from
a
block assigned for 'public internet' use.  They can be from IPv4
RFC-1918 
space, or an IPv6 equivalent, for example.  Or, they _can_ be from a
block
of public internet addresses -- but they don't _have_ to be.  Since it
_is_
an *isolated* network, they could even use addresses in collision with
use
on the public Internet.
>  
> > Likewise government would like to give each home a permanent 
> > subnet from
> > "its addresses" for their use especially including advanced 
> > EMS services
> > such that they can handle both 911 and direct fire alarms.  I
wouldn't
> > be surprised if in a couple decades, your home City/County has your
> > properties IP address on your deed.
>
> I would be surprised.  IP addresses are not property, and are not
> transferable in that sense.  
>  
> > I already have two ISP's serving my home; cable and DSL both and
will
> > probably add an EVDO link with a third.  In my case, because of the
> > incredibly poor physical plant in my area, neither are very
reliable.
> > 
> > Try this list, you can validate it with some of the folks working
> > community networking:
> > - Internet Service Provider
> > - Entertainment Service Provider
> > - Home Application Service Provider
> > - Government Services
> > - Communication Service Provider
> > - Power Provider
> > - Metering Provider
> > - EMS (911 and fire alarm)
> > - Security Service Provider
> > 
> > None of these will be a simple single IP address either as most will
> > have multiple controls or sensors serving your home.
>
> Would a /64 be sufficient for each, do you think?  Especially if
> they're not from a single aggregate block, this would be important
> to understand.
>
> > 
> > And no your ISP will NOT work as the sole provider of my home IP's!
> > I'll personally fight that on capital hill!  
>
> This is the place to fight for that, not Capitol Hill.  
>
> > We fought for the right not
> > to be forced to switch phone numbers when we move and I'm on 
> > my 4th (or
> > 5th) ISP serving my home in the last ten years.  (AT&T, Earthlink,
> > Qwest, MSN, Speakeasy, and Comcast, ok 6th)  All of which provided
me
> > with new IP's and email addresses which had no relation to any my
> > previous ones so I had to contact everyone I emailed with and 
> > have them
> > update my email address.  Bill paying services make this even 
> > worse!  It
> > takes months to get them all updated; one-at-a-time.
>
> Just to make sure I understand your position:
> You'd rather have nine provider aggregated addresses (counting
networks
> above) than one (PI or PA) address?
>
> There are some differences here.  Your choice of local phone carriers
> has been extremely limited.  The local carrier has physical facilities
> to your house; now the cable company and power company also have 
> facilities.  An ISP provides a service using those facilities.  They
> may provide multiple services, including routing (pretty essential,
and
> requiring aggregatable addressing) and maybe also email, but these are

> disjoint: there's no reason your Internet access provider has to be
your
>
> email provider.  
>
>
> > This is exactly why I would prefer a local government provided IP
that
> > was associated with my home address that didn't change until I
moved!
>
> I must have misunderstood your previous points then.  There are a lot
> of points to take away from this sentence:
> 1.  "Local" government meaning city, county, state, federal, or some
> kind of regional Internet registry?
> 2.  You want a government authority to replace the current system of
IP
> address allocation?  Can you outline the ways in which this is
superior
> to the current system?
> 3.  How would IP addresses be "associated with my home address"?
> Do you envision embedding physical address information in the IP 
> address, like GPS coordinates, or a database owned and operated by the
> government?
> 4.  How would routing work?  Would every network have to carry a
> separate
> route for every home?   Or do you mean that local governments should
> take over all Internet access?
>
> > And I certainly don't want to worry that if I change ISP, 911 or
fire
> > won't be able to find me.  Likewise I want to keep my phone 
> > number when
> > I move and my email even if I have to change service providers.
> > 
> > Sorry but my view of the future world has little to do with today's!
>
> That's fair to say.  I don't quite understand whether you favor
> competition, monopolization, or nationalization.  I'm hoping you can
> clarify how routing might work in your vision.  I definitely advise
> you to take advantage of one of the many companies providing free 
> email, so that you don't have to go through the pain of updating your
> contacts next time you switch ISPs.  Or you can set up your own mail
> server, of course.
>
> Lee
>
>
> > 
> > Take care
> > Terry
> > 
> > -----Original Message-----
> > From: Houle, Joseph D (Joe), CMO [mailto:jdhoule at att.com] 
> > Sent: Wednesday, March 15, 2006 4:13 PM
> > To: Davis, Terry L
> > Cc: Lea Roberts; ppml at arin.net
> > Subject: RE: [ppml] a modified proposal 2005-8
> > 
> > Terry:
> >    I hope I am reading your last paragraph incorrectly?   
> >    Are you suggesting these other entities will "allocate to you a
> > subnet or an address" for devices on your location?  
> >    I would hope not, I would hope you have some number of subnets at
> > your location and these other entities will want to communicate with
> > some devices at your location which you have addressed from an
> > aggregated block.  
> >    Right?
> > 
> > Joe Houle
> > 
> > 
> > -----Original Message-----
> > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On 
> > Behalf Of
> > Davis, Terry L
> > Sent: Saturday, March 11, 2006 3:57 PM
> > To: Lea Roberts; ppml at arin.net
> > Subject: Re: [ppml] a modified proposal 2005-8
> > 
> > Lea
> > 
> > The proposal is fine.
> > 
> > But I am actually hard pressed to imagine a single entity 
> > site that will
> > have only a single local subnet under an IP-v6 architecture.  
> > I tend to
> > believe that IP-v6 architectures will be very different from our
> > traditional IP-v4 concepts.
> > 
> > My power, entertain, City, and communications company will probably
> > allocate me one each from there individual spaces but I still think
I
> > will several of my own as I do today.
> > 
> > Take care
> > Terry
> > 
> > -----Original Message-----
> > From: Lea Roberts [mailto:lea.roberts at stanford.edu] 
> > Sent: Saturday, March 11, 2006 12:34 AM
> > To: ppml at arin.net
> > Subject: [ppml] a modified proposal 2005-8
> > 
> > was just sent in to ARIN...  for your additional reading 
> > pleasure. /Lea
> > 
> > 		Policy Proposal 2005-8, version 2:
> > 
> > Proposal to amend ARIN IPv6 assignment and utilisation requirement
> > 
> > This proposal would amend the IPv6 address allocation policies
(ARIN's
> > NRPM, section 6) regarding the definition of the default size of End
> > Site assignments and the threshold value for End Site allocation
> > efficiency, no longer assuming the fixed values for End Site
> > assignments established by RFC3177.  Many references to "/48" will
> > need to be replaced by "End Site assignment".
> > 
> > for example, section 6.5.4.1 should be replaced as follows:
> > 
> >    6.5.4.1. Assignment address space size
> > 
> >    End Users are assigned an End Site assignment from their LIR or
> >    ISP. The exact size of the assignment is a local decision for the
> >    LIR or ISP to make, using a minimum value of a /64 (when only one
> >    subnet is anticipated for the End Site) up to the normal maximum
> >    of /48, except in cases of extra large end sites where a larger
> >    assignment can be justified.
> > 
> >    The following guidelines may be useful (but they are only
> > guidelines):
> > 
> >    - /64 when it is known that one and only one subnet is needed
> > 
> >    - /56 for small sites, those expected to need only a few subnets
> >      over the next 5 years.
> > 
> >    - /48 for larger sites
> > 
> >    For end sites to whom DNS will be delegated, the LIR/ISP should
> >    consider making an assignment on a nibble (4-bit) boundary to
allow
> >    to simplify reverse lookup delegation.
> > 
> >    RIRs/NIRs are not concerned about which address size an LIR/ISP
> >    actually assigns. Accordingly, RIRs/NIRs will not request the
> >    detailed information on IPv6 user networks as they did in IPv4,
> >    except for the cases described in Section 6.4.4 and for the
> >    purposes of measuring utilization as defined in this document.
> > 
> > also, section 6.9 will need to be replaced:
> > 
> >    6.9. IPv6 Reassignments policy
> > 
> >    The size of IPv6 address assignments to End Sites is to be
> >    determined by the ISP/LIR.
> > 
> >    ISPs and LIRs may choose whether to make changes to their
> >    procedures for assigning address blocks to End Sites. The
threshold
> >    End Site allocation efficiency level is between 20% to 50% for
most
> >    ISPs and LIRs when based on a 0.94 HD Ratio. ISPs and LIRs will
> >    need to operate address plans according to this target level of
End
> >    Site allocation efficiency.
> > 
> > 
> > there's a need to change ARIN NRPM IPv6 Utilization:
> > 
> >    The ARIN NRPM Section 6.7 will be amended so its IPv6 allocation
> >    utilization criteria will reflect the use of a /56 as the unit
> >    quantity in the calculation of the ISP or LIR's end site
allocation
> >    efficiency.
> > 
> > Rationale:
> > 
> > The current IPv6 Address Allocation and Assignment Policy (section 6
> > of ARIN's NRPM) indicates that end sites should be allocated a /48
as
> > a uniform allocation unit if using more than one host or one subnet.
> > 
> > This proposal alters the existing policy regarding LIR and ISP
> > assignments to End Sites to allow the unit of assignment to be an
LIR
> > or ISP decision.
> > 
> > In assessing the address utilization efficiency for ISPs or LIRs,
the
> > definition of an End Site for the purposes of the calculation of ISP
> > or LIR End Site allocation efficiency, is to be made 
> > according to a /56
> > size.
> > 
> > This measure, if undertaken generally by all RIRs, in conjunction
with
> > the further measures undertaken by the addressing community
regarding
> > increasing the HD ratio to 0.94, would increase the anticipated
useful
> > lifetime of IPv6 to encompass a period in excess of 100 years, in
> > which case no further allocation policy changes would be
anticipated.
> > 
> > 
> > A more detailed rationale is available in Geoff Huston's 
> > presentation on
> > the subject, at RIPE 50, which can be found at:
> > http://www.ripe.net/ripe/meetings/ripe-50/presentations/ripe50
> > -plenary-w
> > ed-ipv6-roundtable-report.pdf
> > 
> > 
> > 
> > --------------------------------------------------------------
> > ----------
> > 
> > Appendix A. References
> > This material is not formally part of the Policy Proposal. It is
> > included
> > here for informational purposes.
> > 
> > 1. The IPv6 Address Plan - Geoff Huston
> > http://www.potaroo.net/ispcol/2005-07/ipv6size.html
> > 
> > 2. Internet Draft: Issues Related to the Management of IPv6 Address
> > Space -
> > Thomas Narten
> > http://tools.ietf.org/wg/ipv6/draft-narten-iana-rir-ipv6-consi
> derations-
> > 00.txt
> > 
> > [unfortunately, the ID expired, so use the URL:
> > 
> > http://www.cs.duke.edu/~narten/ietf/draft-narten-iana-rir-ipv6
> -considera
> > tions-00.txt]
> > 
> > 
> > 3. Internet Draft: IPv6 Address Allocation to End Sites - 
> > Thomas Narten,
> > Geoff Huston & Lea Roberts
> > http://www.ietf.org/internet-drafts/draft-narten-ipv6-3177bis-
> 48boundary
> > -01.txt
> > 
> > _______________________________________________
> > 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
> > _______________________________________________
> > 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
>

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



More information about the ARIN-PPML mailing list