[ppml] Definition of an (IPv6) End Site
As I said earlier....
My definition would be.....
I would suggest that it implies that the organization's network is not used
to provide for-fee transit to other networks not under their own management.
In addition, depending upon architecture and communication strategy, an
organization might choose to deem a particular element of it's distributed
network a separate end-site, or consider the entire distributed
infrastructure a single end-site.
In such case, the hardware chain and you as an ISP would perhaps jointly
figure out what the best definition is for each independent, or some
aggregate....it's a business and architectural issue.
But, I believe that if each individual HW store is to be deemed and
end-site, then they may be restricted by a policy hurdle to acquire PI
> -----Original Message-----
> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On
> Behalf Of Jason Schiller (schiller at uu.net)
> Sent: Thursday, April 06, 2006 9:14 AM
> To: Thomas Narten
> Cc: ARIN PPML
> Subject: Re: [ppml] Definition of an (IPv6) End Site
> My confusion rests not on who is an end-site, but how many
> end-sites that who is.
> Let me give you an example. Lets say I am and ISP and I have
> a customer that owns a chain of 100 hardware stores across
> the US. Each store is independently operated. Each store
> has a separate Internet connection through me. Each store
> has a single LAN that is only connected to the Internet. The
> stores have no interconnection at all.
> But there is one person at the corporate office that orders
> all of the T1 installs, and all bills are sent to the
> corporate office under a single company name.
> Since there is only one end-user that has a business
> relationship with me, would this only qualify as a single
> end-site, and thus all 100 locations should share a single
> /48? Or can I consider each separate network ate each
> separate location an end-site? In this case I could assign 100 /48s.
> What if the sites are interconnected, in that case should it
> be one end-site?
> What if the sites are interconnected, but each site has a
> different contact, but it is all part of the same compnay, in
> that case should it be one end-site?
> I do understand the other confusion that is going on as well,
> for example how is the IRS an ISP.
> What I want to suggest is if you are trying to tighten the
> language, please also consider the case above .
> Jason Schiller
> Senior Internet Network Engineer
> Public IP Global Network Engineering
> schiller at uu.net
> UUNET / Verizon
> jason.schiller at verizonbusiness.com
> The good news about having an email address that is twice as
> long is that it increases traffic on the Internet.
> On Thu, 6 Apr 2006, Thomas Narten wrote:
> > Date: Thu, 06 Apr 2006 09:54:24 -0400
> > From: Thomas Narten <narten at us.ibm.com>
> > To: ARIN PPML <ppml at arin.net>
> > Subject: [ppml] Definition of an (IPv6) End Site
> > > We've been 'round and 'round on this before; the
> definition of "end
> > > site" is obviously inadequate.
> > If there is confusion, by definition it's inadequate! :-)
> > > I'd propose that a single network with private
> connectivity between
> > > locations should count as a single "site". This roughly
> > > with who qualifies for an ASN. If the number of
> > > within that AS justifies it, they would qualify for a
> larger prefix
> > > than /48.
> > I tend to agree. Speaking as a participant in the
> discussions that led
> > to the original policy (and the current wording), there was a clear
> > intention to split the world into two groups:
> > - those that provide internet connectivity to customers
> (i.e., ISPs),
> > where the customers are not the same organization/company as the
> > provider, and where there are many _different_ customers, and in
> > particular not just separate "offices" in a larger businesses.
> > - End sites, those that use the internet, get internet service from
> > ISPs and whose core business is not providing network services to
> > others.
> > Obviously, there are boundary cases that are tricky. But
> the overall
> > context here was that in order to get good aggregation (and
> > bounded routing tables), you wanted ISPs to aggregate addresses for
> > _many_ end users, i.e., customers. Doing otherwise would
> run the risk
> > of (essentially) giving PI space to end users in an unscalable way.
> > Quoting from the official (current) text:
> > > 6.2.9. End site
> > >
> > > An end site is defined as an end user (subscriber) who has a
> > > business relationship with a service provider that involves:
> > >
> > > 1. that service provider assigning address space to the end user
> > >
> > > 2. that service provider providing transit service for
> the end user
> > > to other sites
> > >
> > > 3. that service provider carrying the end user's traffic.
> > >
> > > 4. that service provider advertising an aggregate prefix
> route that
> > > contains the end user's assignment
> > In my mind, the above was intended to apply to separate
> > businesses/organizations, and not large companies that have
> > IT divisions. What we didn't want is to allow end sites to
> simply set
> > up shell orgnizations so that they would look like LIRs on paper.
> > If we really wanted large end sites to get PI space, a
> separate policy
> > should be developed (as is being discussed now).
> > And, one of the other goals above is that all of the
> customer address
> > ranges are covered (in the global routing tables) by a single
> > aggregate prefix.
> > For many large end sites, this is not what is really
> desired. I.e., if
> > someone has large offices in (say) US, Europe and Japan, it
> may well
> > be that each of those sites wants to be connected to the
> Internet via
> > local ISPs, rather than via (say) the US location (with everything
> > routed via the US connect point). But if this sort of local
> > connectivity is desired, having a single aggregate that gets
> > advertised (by giving the end site a PI assignment) doesn't
> happen in
> > practice, raising the question of whether a PI assignment
> makes sense
> > in the way people are claiming they are needed.
> > Thomas
> > _______________________________________________
> > PPML mailing list
> > PPML at arin.net
> > http://lists.arin.net/mailman/listinfo/ppml
> PPML mailing list
> PPML at arin.net