Actually, requiring a public whois record is the way it always has been, that's 
only recently changed.   I think most folks would agree that, IPv4 /32 :: IPv6 
/128 as IPv4 /29 :: IPv6 /64  So, while you are right, that swip'ing a v4 /32 
has never been required, I think your analogy of a v6 /64 to a v4 /32 is off.  
The minimum assignment requiring a swip is also ensconced in RIR policy.  If 
you don't like it, may I suggest you propose policy to change it?

RIPE's policy:
" When an End User has a network using public address space this must be 
registered separately with the contact details of the End User. Where the End 
User is an individual rather than an organisation, the contact information of 
the service provider may be substituted for the End Users."

  Note the *may* -- ISP's aren't required to support it. 

More RIPE policy.. 
"When an organisation holding an IPv6 address allocation makes IPv6 address 
assignments, it must register these assignments in the appropriate RIR database.

These registrations can either be made as individual assignments or by 
inserting a object with a status value of 'AGGREGATED-BY-LIR' where the 
assignment-size attribute contains the size of the individual assignments made 
to End Users.When more than a /48 is assigned to an organisation, it must be 
registered in the database as a separate object with status 'ASSIGNED'."

    So they have to register it, and they get a choice about how they do it.. 
Your provider has chosen a way you don't like.  Talk to them about it, rather 
than complaining on NANOG? 


 It's pretty similar in the ARIN region.  In 2004, the ARIN community passed 
the residential customer privacy policy - specifically allowing ISP's to 
designate a record private.  Again, it's optional. 

https://www.arin.net/policy/nrpm.html


Min assignment swip
6.5.5.1. Reassignment information

Each static IPv6 assignment containing a /64 or more addresses shall be 
registered in the WHOIS directory via SWIP or a distributed service which meets 
the standards set forth in section 3.2. Reassignment registrations shall 
include each client's organizational information, except where specifically 
exempted by this policy.


IPv4
4.2.3.7.3.2. Residential Customer Privacy

To maintain the privacy of their residential customers, an organization with 
downstream residential customers holding /29 and larger blocks may substitute 
that organization's name for the customer's name, e.g. 'Private Customer - XYZ 
Network', and the customer's street address may read 'Private Residence'. Each 
private downstream residential reassignment must have accurate upstream Abuse 
and Technical POCs visible on the WHOIS directory record for that block. 

IPv6
6.5.5.3. Residential Subscribers
6.5.5.3.1. Residential Customer Privacy

To maintain the privacy of their residential customers, an organization with 
downstream residential customers holding /64 and larger blocks may substitute 
that organization's name for the customer's name, e.g. 'Private Customer - XYZ 
Network', and the customer's street address may read 'Private Residence'. Each 
private downstream residential reassignment must have accurate upstream Abuse 
and Technical POCs visible on the WHOIS record for that block.


--Heather


-----Original Message-----
From: Constantine A. Murenin [mailto:[email protected]] 
Sent: Saturday, December 08, 2012 12:46 AM
To: [email protected]
Subject: Why do some providers require IPv6 /64 PA space to have public whois?

Hello,

I personally don't understand this policy.  I've signed up with hetzner.de, and 
I'm trying to get IPv6; however, on the supplementary page where the 
complementary IPv6 /64 subnet can be requested (notice that it's not even a 
/48, and not even the second, routed, /64), after I change the selection from 
requesting one additional IPv4 address to requesting the IPv6 /64 subnet (they 
offer no other IPv6 options in that menu), they use DOM to remove the IP 
address justification field ("Purpose of use"), and instead statically show my 
name, physical street address (including the apartment number), email address 
and phone number, and ask to confirm that all of this information can be 
submitted to RIPE.

They offer no option of modifying any of this; they also offer no option of 
hiding the street address and showing it as "Private Address" instead; they 
also offer no option of providing contact information different from the 
contact details for the main profile or keeping a separate set of contact 
details in the main profile specifically for RIPE; they also offer no option of 
providing a RIPE handle instead (dunno if one can be registered with a "Private 
Address" address, showing only city/state/country and postal code; I do know 
that with ARIN and PA IPv4 subnets you can do "Private Address" in the Address 
field); they also don't let you submit the form unless you agree for the 
information shown to be passed along to RIPE for getting IPv6 connectivity 
(again, no IPv6 is provided by default or otherwise).

Is this what we're going towards?  No probable cause and no court orders for 
obtaining individually identifying information about internet customers with 
IPv6 addresses?  In the future, will the copyright trolls be getting this 
information directly from public whois, bypassing the internet provider abuse 
teams and even the most minimal court supervision?  Is this really the 
disadvantage of IPv4 that IPv6 proudly fixes?  I certainly have never heard of 
whois entries for /32 IPv4 address allocations!

Anyhow, just one more provider where it's easier to use HE's tunnelbroker.net 
instead of obtaining IPv6 natively; due to the data-mining and privacy concerns 
now.  What's the point of native IPv6 connectivity again?  In hetzner.de terms, 
tunnelbroker.net even provides you with the failover IPv6 address(es), 
something that they themselves only offer for IPv4!

Is it just me, or are there a lot of other folks who use tunnelbroker.net even 
when their ISP offers native IPv6 support?
Might be interesting for HE.net to make some kind of a study. :-)

Cheers,
Constantine.


Reply via email to