[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