[arin-ppml] Customer Confidentially and IPv6

[Owen DeLong]

On Jan 29, 2010, at 11:38 AM, Leo Bicknell wrote:

> In a message written on Fri, Jan 29, 2010 at 11:04:47AM -0800, Owen DeLong wrote:
>>   Actually, as I interpret the NRPM, they would be required to put the
>>   covering prefix of the DHCP pool into SWIP as a DHCP Pool, but,
>>   there is no need for the DHCP daemon to update SWIPS.
>>   If that isn't the case, you are correct that that area of policy needs
>>   work.
> 
> Based on what is said in sections 6.5.4.4 and 6.5.5 I don't share
> your view.  It seems to me the manual is clear, if an ISP assigns
> a /48 to someone then it must be registered via SWIP, with the
> possible caveat of 6.5.5.1 which allows for the customer name to
> be replaced with "Private Customer".
> 
> I don't see anything that would make this not true if the assignment
> was done via DHCP-PD.
> 
>>   However, for static persistent assignments of /56s or shorter prefixes
>>   to customers, I think it is perfectly reasonable to require SWIP just
>>   as we require it for /29 and shorter today. I do not see a need to
>>   expand customer anonymity beyond the current residential
>>   requirement.
> 
> Let me assume your previous interpretation is right.  A /48 assigned
> via DHCP-PD to a cable modem customer (as an example) is not required
> to have a SWIP entry.  However, a /48 assigned statically is required
> to have a SWIP entry.
> 
> How does that make any sense?  What if I make the DHCP-PD "static",
> e.g.  enter the MAC and prefix in the DHCP server, so the client
> always gets the same range.  Does it now qualify for a SWIP entry?
> 
Yes, I would expect that to require a SWIP.  The point is that transient
assignments (assignments which can change downstream responsibility
on a regular basis) do not make sense to SWIP.

While it is true that IPv4 didn't have transient assignments for more than
a single address, and IPv6 does, I still think that it is both technically
infeasible and practically unreasonable to expect SWIP templates
to be submitted to ARIN by DHCP daemons issuing prefixes on a
transient basis.  If you statically configure the prefix to the MAC address
then you should SWIP it at the same time.  That's no longer a transient
assignment.  However, in a case where the assignee is not known
until the DHCP daemon makes the assignment, and, where the
assignment goes away in a similarly automated fashion at some
later date, SWIP does not make sense, IMHO.

> In IPv4, it's highly likely that a megacorp (GM?) will have something
> larger than a /29, and have a SWIP entry.  It's also highly likely
> that a person (residental customer) will have something smaller
> than a /29, and thus not be SWIPed.  As IPv4 scarecity continues,
> this is likely to be more true.
> 
Yes.

> In IPv6 that's not so.  The megacorp can likely live in a /48.  A
> residential customer is just as likely to get the same /48.  The
> old probabilities don't apply anymore.
> 
I think it is far more likely that we'll end up with residential customers
getting /56s in most cases, but, time will tell.  In either case, if a
residential customer gets a /48 static assignment, then, they should
be SWIP'd just as /29 residential customers are today.  I don't
see the issue.

> In case my position, in both IPv4 and IPv6 was not clear, I believe
> several things:
> 
> * No residential customer should ever have their personal information in
>  WHOIS for any reason.
> 

I'm mostly willing to accept this.  I don't believe that the current requirement
for City, State, Zip is unreasonable.

> * Contact information in whois should lead to the entity /most likely to
>  help/.  I am extremely skeptical that putting folks as wide ranging as
>  Grandma to many small businesses is going to lead to that result, I
>  think in almost all cases their upstream ISP is a better place to go.
> 
Yes and no. I think that Contact information serves a multitude of purposes,
including a transparency of process and public audit function.  As such,
I think that having the contact information (within limits) is worth while.

I'm not advocating that Grandma be in there (other than as currently
required in IPv4), nor am I advocating that the upstream ISP be
difficult to find.

> * ARIN should devise policies and procedures such that it requires the 
>  minimum level of effort for an ISP to comply.
> 
To some extent, yes. However, I think that transparency in the process
and open access to information about utilization of a public resource
holds a higher priority than ISP convenience.

> Rather than have millions of /29 records in the database, I'd rather see
> records like:
> 
> NetRange:    10.15.0.0 - 10.15.31.255
> CIDR:        10.15.0.0/11
> NetName:     CableFOO-Chicago-12
> Comment:     Statically assigned residential cable modem customers in 
>             the Chicago area.
> Usage:       212,453 subnets of 262144 in use on 2009-01-29.
> 
> OrgAbuseHandle: CableFOO-ABUSE-ARIN
> OrgAbuseName:   CableFOO Inc Abuse Department
> OrgAbusePhone:  +1 800 4BOTNET
> OrgAbuseEmail:  abuse-chiago at cablefoo.com
> 
> Where the usage data was updated on some periodic interval, perhaps say
> quarterly.
> 
On this we completely disagree.

This is far too little information for any form of public audit or research
function and it invites abuses such as getting subnets from N
providers in order to get N times the amount of address space you
can justify.  This is likely less of an issue in IPv6, but, it's certainly
a concern in IPv4.

> It protects peoples privacy, provides usage information ARIN needs and
> makes it visable to the community, directs people to contact information
> that is likely to get someone who can help, and greatly reduces the
> burden on the ISP and ARIN to process tons of SWIP templates, 99% of
> which just say "Private Customer" and "Private Residence" anyway.
> 
I think it does not make enough information visible to the community.

I think that in the case of a botted host, CableFOO is far less likely to
be able to (or willing to) help me get their customer's one of 50
machines disconnected from the net than the customer themselves.

Owen