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.
On 12/7/12, Constantine A. Murenin <mureninc@gmail.com> wrote: [snip] It seems you have an issue with the automated system of one provider in your RIR service region. This is unusual, I think; for the provider to not ask what NIC handle, or WHOIS detail should be listed for an assignment. I would suggest calling up the provider, and attempt to work out a solution with them where you get a /64, and the contact you want listed in WHOIS. The provider suballocating a block of IP addresses, can obviously apply additional policy to them -- such as additional requirements on what is shown in WHOIS. However, you can pick a different provider if necessary...... -- -J
In message <CAAAwwbUbWwK09vPfLJ89HyiupP5pP7ZypBhAbM4WMhFHe-=XWw@mail.gmail.com>, Jimmy Hess writes:
On 12/7/12, Constantine A. Murenin <mureninc@gmail.com> wrote: [snip]
It seems you have an issue with the automated system of one provider in your RIR service region. This is unusual, I think; for the provider to not ask what NIC handle, or WHOIS detail should be listed for an assignment. I would suggest calling up the provider, and attempt to work out a solution with them where you get a /64, and the contact you want listed in WHOIS.
The provider suballocating a block of IP addresses, can obviously apply additional policy to them -- such as additional requirements on what is shown in WHOIS.
However, you can pick a different provider if necessary......
-- -J
It's also more than likely a hold over of IPv4 think where, generally, only companies are allocated address blocks. I would be ringing the ISP and talking to the staff escalating until you get to someone who understands the issue. Also a /64 is ridiculously small for a company and it really too small for individuals so it very much looks like this ISP hasn't applied enough thought to this area. Trail blazing is hard work but someone has to do it. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On 8 December 2012 13:03, Mark Andrews <marka@isc.org> wrote:
It's also more than likely a hold over of IPv4 think where, generally, only companies are allocated address blocks. I would be ringing the ISP and talking to the staff escalating until you get to someone who understands the issue. Also a /64 is ridiculously small for a company and it really too small for individuals so it very much looks like this ISP hasn't applied enough thought to this area. Trail blazing is hard work but someone has to do it.
This might be a good advice for a home or an office obtaining internet connectivity with a dynamic IP address or at a location remote from an he.net POP. However, it's not something that I am, as an individual renting a single server at a great price and only 5ms from Frankfurt, an HE.net POP, is willing to go through. Why go through all the hoops where HE's tunnelbroker.net already provides the same service, but with shorter addresses and better latency, and without any self-made RIPE-blamed headaches and extra rules? Also, specifically in regards to hetzner.de, if I'd like to switch from one of their servers to another, a tunnelbroker.net-issued address will let me have a seamless "failover", whereas a native IPv6 /64 from hetzner.de might have to be given up and obtained anew (and one might again have to go through all the hoops in order to obtain a new one). I've tried contacting their support through their web-interface, but they've repeatedly claimed that I've agreed to have my data provided to RIPE. ??? But then, again, I don't speak any German; and they, obviously, have to minimise their costs by a great deal of automation in order to keep their prices low. At this point, I don't see a single good reason of why I should continue bothering them, instead of simply using what already works great -- tunnelbroker.net. Frankly, the more I think about this, the less it's clear why someone like hetzner.de would actually want you to be using their native IPv6 support, instead of the one provided by HE.net through their free tunnelbroker.net service. HE has an open-peering policy (AFAIK); which basically means that tunnelbroker.net traffic is free for hetzner.de, whereas for native IPv6 traffic they might have to be paying for transit costs, depending on the destination. HE.net probably wins, too; since being the place-to-go-for-IPv6 might make it easier for them to have more settlement-free peering with big transit providers such as AT&T (Bay-Area-wise, they still have IPv6 traffic going through their peering in Los Angeles). C.
Hi, hmm, they get away with it once again. On the other hand their prices stay low. Off-topic but somehow important to me:
HE has an open-peering policy (AFAIK); which basically means that tunnelbroker.net traffic is free for hetzner.de
Is that true? That would be great! Regards Dan
On Sat, Dec 8, 2012 at 7:12 PM, Dan Luedtke <mail@danrl.de> wrote:
Off-topic but somehow important to me:
HE has an open-peering policy (AFAIK); which basically means that tunnelbroker.net traffic is free for hetzner.de
Is that true? That would be great!
Just because companies A and B don't have a customer relationship doesn't mean all their interactions with each other are free. So no, it's not true. Costs come from needing to buy bigger routers, bigger waves or fiber to the exchanges, bigger ports on the exchanges, etc. "Peering is a scam." -- Darius Jahandarie
On Dec 08, 2012, at 21:14 , Darius Jahandarie <djahandarie@gmail.com> wrote:
On Sat, Dec 8, 2012 at 7:12 PM, Dan Luedtke <mail@danrl.de> wrote:
Off-topic but somehow important to me:
HE has an open-peering policy (AFAIK); which basically means that tunnelbroker.net traffic is free for hetzner.de
Is that true? That would be great!
Just because companies A and B don't have a customer relationship doesn't mean all their interactions with each other are free.
So no, it's not true. Costs come from needing to buy bigger routers, bigger waves or fiber to the exchanges, bigger ports on the exchanges, etc.
"Peering is a scam."
The vast majority of AS-AS boundaries on the Internet are settlement free peering. I guess that makes the Internet a scam. As for the costs involved, "free" is a relative term. Most people think of peering as "free" because there is zero marginal cost. Kinda. Obviously if you think of your 10G IX port as a sunk cost, pushing 11 Gbps over it is not 'free' as you have to upgrade. But again, most people understand what is meant. Bigger waves & bigger routers are not due to peering, they are due to customer traffic - you know, the thing ISPs sell. Put another way, this is a Good Thing (tm). Or at least it should be. Unless, of course, you are trying to convince us all that selling too many units of your primary product is somehow bad. Peering allows you, in most cases, to lower the Cost Of Goods Sold on that product. Again, usually a Good Thing (tm). Unless you are again trying to convince us all that selling at a higher margin (we'll ignore the lower latency & better overall experience) is somehow bad. -- TTFN, patrick
That's a really good point, Patrick. We've received an interesting analysis from our customers recently where they reviewed the accounting on all the services they need in order to peer off approximately 1/3rd of their total traffic. They took their national wavelength cost, local access, colocation at carrier-neutral facilities at it came to roughly $.95/mbps. Although this is considerably less than what they spend on transit, their analysis failed to consider depreciation on their capital (routers and other hardware), associated warranty costs and the incremental operational overhead to operate a large national network. When all is said and done, they are probably spending as much on "free peering" as they are on transit. In the case of this customer they would have a lower total cost by simply staying regional and purchasing transit. In other cases, peering will only lower your marginal cost if there are strategic reasons for building and maintaining that backbone. Dave -----Original Message----- From: Patrick W. Gilmore [mailto:patrick@ianai.net] Sent: Saturday, December 08, 2012 8:23 PM To: NANOG list Subject: Re: Why do some providers require IPv6 /64 PA space to have public whois?
So no, it's not true. Costs come from needing to buy bigger routers, bigger waves or fiber to the exchanges, bigger ports on the exchanges, etc.
"Peering is a scam."
The vast majority of AS-AS boundaries on the Internet are settlement free peering. I guess that makes the Internet a scam. As for the costs involved, "free" is a relative term. Most people think of peering as "free" because there is zero marginal cost. Kinda. Obviously if you think of your 10G IX port as a sunk cost, pushing 11 Gbps over it is not 'free' as you have to upgrade. But again, most people understand what is meant. Bigger waves & bigger routers are not due to peering, they are due to customer traffic - you know, the thing ISPs sell. Put another way, this is a Good Thing (tm). Or at least it should be. Unless, of course, you are trying to convince us all that selling too many units of your primary product is somehow bad. Peering allows you, in most cases, to lower the Cost Of Goods Sold on that product. Again, usually a Good Thing (tm). Unless you are again trying to convince us all that selling at a higher margin (we'll ignore the lower latency & better overall experience) is somehow bad. -- TTFN, patrick
On Sat, Dec 8, 2012 at 10:23 PM, Patrick W. Gilmore <patrick@ianai.net> wrote:
The vast majority of AS-AS boundaries on the Internet are settlement free peering. I guess that makes the Internet a scam.
As for the costs involved, "free" is a relative term. Most people think of peering as "free" because there is zero marginal cost. Kinda. Obviously if you think of your 10G IX port as a sunk cost, pushing 11 Gbps over it is not 'free' as you have to upgrade. But again, most people understand what is meant.
Bigger waves & bigger routers are not due to peering, they are due to customer traffic - you know, the thing ISPs sell. Put another way, this is a Good Thing (tm). Or at least it should be. Unless, of course, you are trying to convince us all that selling too many units of your primary product is somehow bad.
Peering allows you, in most cases, to lower the Cost Of Goods Sold on that product. Again, usually a Good Thing (tm). Unless you are again trying to convince us all that selling at a higher margin (we'll ignore the lower latency & better overall experience) is somehow bad.
The quote was tongue-in-cheek, of course. I don't agree that "most people understand what is meant". I can't count the number of companies that unnecessarily get waves to exchanges and colocate there because they think peering there will reduce their costs, when it does not. I was not trying to argue that more traffic is bad. I'm just trying to argue that there are certain (often neglected) costs that you would only have with peering that you could avoid when not peering, and that it's more than just the exchange port. Also, it's a different topic, but I really don't think "tier 3s" (sigh) peering on public exchanges increases quality generally. It (usually) does decrease latency, but there is generally a lack of redundancy in most peering setups that is glaring when there is a failure somewhere. Of course, if you're a very competent network operator, you can have lots of redundancy for your peering, both at the edge and internally (in terms of doing the traffic engineering needed when you have lots of different paths traffic can take), but I'd say this is not the sort of setup a standard regional operator would have. -- Darius Jahandarie
On 8 December 2012 16:12, Dan Luedtke <mail@danrl.de> wrote:
Hi,
hmm, they get away with it once again. On the other hand their prices stay low.
Off-topic but somehow important to me:
HE has an open-peering policy (AFAIK); which basically means that tunnelbroker.net traffic is free for hetzner.de
Is that true? That would be great!
That's not actually off-topic, but the whole point of my thread: It's being implied everywhere that native IPv6 is somehow important to seek, since we're running out of IPv4 addresses. I myself have recently trolled on LowEndBox.com, annoying every new provider with a "it's 2012, do you support IPv6?"-style questions. Until I then signed up with a couple of such established providers that did clearly advertise "IPv6 support", and realised that, as long as there's tunnelbroker.net, "native IPv6" is nothing more than purely a marketing concept in situations where you are already getting a dedicated server (either virtual or physical) as setting up a reliable tunnel on such a server is just so damn easy, reliable, fast and hassle-free. I still think that native IPv6 is important for end-users at home and on the go from the operator's perspective (T-Mobile USA is practically ready to shutdown IPv4 w/ NAT44 and go with IPv6 + NAT64 + DNS64 + 464XLAT), but for individual servers close to an IX with HE.net, where all native IPv4/IPv6 traffic has to go through that very same Internet eXchange point anyways, native IPv6 can only be slower, more expensive, more insecure and less feature rich. And the providers have no incentives (quite the opposite, as I've contemplated above), since it's not like in the server room they could drop IPv4 support any time soon anyways -- no client would approve. In summary, I'd be very happy to try out hetzner.de's native IPv6 if they sort it out one day and will offer short, abbreviatable addresses, and without violating my privacy; until then, I'm very happy with their prices and being a proven shop, and still happy to be their customer with a bring-your-own IPv6 aka tunnelbroker.net. :-) C.
On Sat, 8 Dec 2012, Constantine A. Murenin wrote:
It's being implied everywhere that native IPv6 is somehow important to seek, since we're running out of IPv4 addresses.
Ok, so I'll give you that tunneling a really short bit, tunneling isn't too bad, but native is most of the time better. 5+ years back we used to run 6bone for out IPv6 connectivity. It was hugely broken. As soon as we started running native ipv6 in the core and started peering natively, quality improved hugely. So yes, 6RD or alike where tunneling is done locally within the ISP or very close to it, is a valid deployment scenario, but middle/long term, native is better. And IPv6 is not a short term fix for IPv4 address runout, it's a long term solution for it. As humankind, we just failed to get it deployed in time for the long term solution to be widely available before we ran out of IPv4 addresses. -- Mikael Abrahamsson email: swmike@swm.pp.se
Ok, so I'll give you that tunneling a really short bit, tunneling isn't too bad, but native is most of the time better.
So sad that some companies mess up in such a way that their customers rather tunnel than use their native infra... :-(
The ISPs are unfortunately behind what the tunnel providers have supplied. It is what it is. Even 'companies' who were told by early adopters and said "we should focus" didn't. The result is :) Steve
On Dec 9, 2012, at 2:58 AM, Randy Bush <randy@psg.com> wrote:
reliable tunnel
bzzzt! oxymoron alert!!!
Intellectually I want to agree with you, but after some reflection... We use lots of tunnels at my org - the IPsec variety. A quick non-scientific query of our monitoring logs reveals that our tunnels are exactly as reliable as the circuits and routers which underneath them. MTU issues aren't really a problem for us either, but then again we do control all the devices at at least one end if the tunnel. I defer to your experience and reputation Randy, and im syre you're right. But where are all these horrifically unreliable tunnels?
reliable tunnel bzzzt! oxymoron alert!!! We use lots of tunnels at my org - the IPsec variety.
as does iij, very heavily. and it has some issues.
A quick non-scientific query of our monitoring logs reveals that our tunnels are exactly as reliable as the circuits and routers which underneath them.
I defer to your experience and reputation
that would be almost as foolish as i am there is significant measurement and screaming showing the issues with v6 tunnel connectivity. geoff, of course. and then a bunch of us have been burned at conferences where the v6 was tunneled. yes, it can be better than no v6 at all. but we're well beyond the days where we bet our businesses on tuneled v6 transport. randy
On Sun, 9 Dec 2012, Ryan Malayter wrote:
But where are all these horrifically unreliable tunnels?
6to4 is one example. I'd say since PMTUD is too often broken on IPv4 (if the tunneling routers even react properly to PMTUD need-to-frag messages for their tunnel packets) in combination with some ISPs supporting jumbo frames internally, makes a lot of tunneling work badly. So you might use tunnel broker tunnels that handle tunnel packet fragmentation for 1500 byte payload over 1500 byte infrastructure and that makes you feel they are reliable. My tunnels to my home where I run routing protocol over the tunnels to two separate tunnel routers at the ISP end (I control all endpoints) plus running ipv6 MTU 1400 in my home to avoid PTMUD for all TCP connections is also a very reliable setup, but I'd rather have native IPv6 and 1500 MTU end-to-end. -- Mikael Abrahamsson email: swmike@swm.pp.se
Frankly, the more I think about this, the less it's clear why someone like hetzner.de would actually want you to be using their native IPv6 support, instead of the one provided by HE.net through their free tunnelbroker.net service. HE has an open-peering policy (AFAIK);
Yes, HE has a one-word peering policy… "YES!" However, that means that if hetzner peered IPv6 native with us, we would provide them every thing you get through tunnel broker still at no cost and without any limitations on bandwidth. We don't artificially limit the bandwidth on tunnel broker, but, each tunnel broker server has a single network interface that it hairpins the v4/v6 traffic on and the bandwidth is what it is. I don't expect that will be an issue any time soon, but for planning purposes, people should understand that tunnel broker is a where-is-as-is service on a best effort basis with no SLA. We do offer production grade tunnel services for a fee and people are welcome to contact me off-list for more information.
which basically means that tunnelbroker.net traffic is free for hetzner.de, whereas for native IPv6 traffic they might have to be paying for transit costs, depending on the destination. HE.net
We would really rather see such traffic come native across our peering links as much as possible. It allows us to provide a higher quality of service.
probably wins, too; since being the place-to-go-for-IPv6 might make it easier for them to have more settlement-free peering with big transit providers such as AT&T (Bay-Area-wise, they still have IPv6 traffic going through their peering in Los Angeles).
Being a popular IPv6 peer and having so many tunnel broker users has been a great success story for us, yes. However, in terms of how this affects our standing for peering, I think that the effect is the same regardless of whether we are passing the traffic from/to a peering link or a tunnel broker. Owen
On 8 December 2012 23:10, Owen DeLong <owen@delong.com> wrote:
Frankly, the more I think about this, the less it's clear why someone like hetzner.de would actually want you to be using their native IPv6 support, instead of the one provided by HE.net through their free tunnelbroker.net service. HE has an open-peering policy (AFAIK);
Yes, HE has a one-word peering policy… "YES!"
However, that means that if hetzner peered IPv6 native with us, we would provide them every thing you get through tunnel broker still at no cost and without any limitations on bandwidth.
We don't artificially limit the bandwidth on tunnel broker, but, each tunnel broker server has a single network interface that it hairpins the v4/v6 traffic on and the bandwidth is what it is. I don't expect that will be an issue any time soon, but for planning purposes, people should understand that tunnel broker is a where-is-as-is service on a best effort basis with no SLA.
We do offer production grade tunnel services for a fee and people are welcome to contact me off-list for more information.
which basically means that tunnelbroker.net traffic is free for hetzner.de, whereas for native IPv6 traffic they might have to be paying for transit costs, depending on the destination. HE.net
We would really rather see such traffic come native across our peering links as much as possible. It allows us to provide a higher quality of service.
Are you suggesting that it's an official/semi-official policy to allow IPv6 peering clients to use HE.net as their default route for IPv6? (To no surprise, that seems to contradict http://he.net/peering.html.) Because, essentially, if you allow settlement-free peering with IPv4, and include tunnelbroker.net into it, then, indeed, a major hosting provider, by having a poor native IPv6 support, can indirectly save a few pennies by forcing some clients to instead use tunnelbroker.net and thus bypass having to pay for any kind of IPv6 transit on behalf of such clients, since any traffic requiring transit when native, will qualify for peering once tunnelled. I'm curious if anyone actually does now, or have attempted in the past, any such traffic laundering by design and on purpose. :-) I guess in the end, the scenario is more hypothetical and conspiracy-driven, since such attempts will either never be statistically significant enough to be noticed, or would be obvious enough to warrant some immediate manual intervention against the misbehaving peer. To HE's credit, I do recall hearing from someone that HE.net is nice enough to not restrict other network operators to choose whether they want to do settlement-free peering or transit, and is very flexible to allow doing both at the same time (unlike AT&T, which explicitly documents that they will never peer with anyone who buys transit from them). As an end user, I still don't understand how you can afford to carry all that traffic globally between the POPs for free; but I'm not complaining. :-) I guess it's a great way to be spending most of your marketing budget in house. :-) You obviously have to justify the need for native connectivity; but, honestly, for my situation (one value server in a given DC) I still see it as a marketing talk that native IPv6 is somehow better than tunnelled. As an end user, I honestly think I have more flexibility with the tunnelled service (and without any extra price). And, as people have pointed out, tunnelled service is usually as reliable as the underlying connection; meaning, in the hosting setting there should really be no problems with tunnels whatsoever. On the other hand, native IPv6 would be quite easy to get wrong; in fact, very easy to get wrong, as I have personally learnt.
probably wins, too; since being the place-to-go-for-IPv6 might make it easier for them to have more settlement-free peering with big transit providers such as AT&T (Bay-Area-wise, they still have IPv6 traffic going through their peering in Los Angeles).
Being a popular IPv6 peer and having so many tunnel broker users has been a great success story for us, yes. However, in terms of how this affects our standing for peering, I think that the effect is the same regardless of whether we are passing the traffic from/to a peering link or a tunnel broker.
Yes; but I was referring to the free transit that you effectively offer through the tunnel broker; such traffic would otherwise go to AT&T through a transit provider, which may or may not be HE. C.
On Dec 10, 2012, at 6:53 PM, Constantine A. Murenin <mureninc@gmail.com> wrote:
On 8 December 2012 23:10, Owen DeLong <owen@delong.com> wrote:
Frankly, the more I think about this, the less it's clear why someone like hetzner.de would actually want you to be using their native IPv6 support, instead of the one provided by HE.net through their free tunnelbroker.net service. HE has an open-peering policy (AFAIK);
Yes, HE has a one-word peering policy… "YES!"
However, that means that if hetzner peered IPv6 native with us, we would provide them every thing you get through tunnel broker still at no cost and without any limitations on bandwidth.
We don't artificially limit the bandwidth on tunnel broker, but, each tunnel broker server has a single network interface that it hairpins the v4/v6 traffic on and the bandwidth is what it is. I don't expect that will be an issue any time soon, but for planning purposes, people should understand that tunnel broker is a where-is-as-is service on a best effort basis with no SLA.
We do offer production grade tunnel services for a fee and people are welcome to contact me off-list for more information.
which basically means that tunnelbroker.net traffic is free for hetzner.de, whereas for native IPv6 traffic they might have to be paying for transit costs, depending on the destination. HE.net
We would really rather see such traffic come native across our peering links as much as possible. It allows us to provide a higher quality of service.
Are you suggesting that it's an official/semi-official policy to allow IPv6 peering clients to use HE.net as their default route for IPv6?
Let me be clear. We offer free IPv6 transit on all IPv6 peering sessions. We do that by advertising all known IPv6 prefixes to you. We fully expect you will not point default at us. However, there is no need to do so as we will, by default and unless you ask otherwise, advertise all IPv6 prefixes known to you.
(To no surprise, that seems to contradict http://he.net/peering.html.) Because, essentially, if you allow settlement-free peering with IPv4, and include tunnelbroker.net into it, then, indeed, a major hosting provider, by having a poor native IPv6 support, can indirectly save a few pennies by forcing some clients to instead use tunnelbroker.net and thus bypass having to pay for any kind of IPv6 transit on behalf of such clients, since any traffic requiring transit when native, will qualify for peering once tunnelled. I'm curious if anyone actually does now, or have attempted in the past, any such traffic laundering by design and on purpose. :-) I guess in the end, the scenario is more hypothetical and conspiracy-driven, since such attempts will either never be statistically significant enough to be noticed, or would be obvious enough to warrant some immediate manual intervention against the misbehaving peer.
I don't know of anyone doing so, but I really can't see a reason why they would. We'll happily accept all traffic to all valid IPv6 destinations known in our routing tables over any peering connection.
To HE's credit, I do recall hearing from someone that HE.net is nice enough to not restrict other network operators to choose whether they want to do settlement-free peering or transit, and is very flexible to allow doing both at the same time (unlike AT&T, which explicitly documents that they will never peer with anyone who buys transit from them).
Correct. We will always localpref the paid connection, but we are happy to simultaneously peer and sell bandwidth to our customers.
As an end user, I still don't understand how you can afford to carry all that traffic globally between the POPs for free; but I'm not complaining. :-) I guess it's a great way to be spending most of your marketing budget in house. :-)
Well, I can't give out all of the details, but, what I can say is that there is monetary value in being well liked by your customers and your potential customers.
You obviously have to justify the need for native connectivity; but, honestly, for my situation (one value server in a given DC) I still see it as a marketing talk that native IPv6 is somehow better than tunnelled. As an end user, I honestly think I have more flexibility with the tunnelled service (and without any extra price). And, as people have pointed out, tunnelled service is usually as reliable as the underlying connection; meaning, in the hosting setting there should really be no problems with tunnels whatsoever. On the other hand, native IPv6 would be quite easy to get wrong; in fact, very easy to get wrong, as I have personally learnt.
There are MTU and performance penalties. They may be small in your specific situation. They may not be so small on the return path in some cases. If tunnels are working well for you, then who cares what anyone else has to say about it. Use a tunnel. However, there's no cost difference between native and tunneled if you are present at an HE connected exchange point, so, it's entirely up to your ISP how they want to do it.
probably wins, too; since being the place-to-go-for-IPv6 might make it easier for them to have more settlement-free peering with big transit providers such as AT&T (Bay-Area-wise, they still have IPv6 traffic going through their peering in Los Angeles).
Being a popular IPv6 peer and having so many tunnel broker users has been a great success story for us, yes. However, in terms of how this affects our standing for peering, I think that the effect is the same regardless of whether we are passing the traffic from/to a peering link or a tunnel broker.
Yes; but I was referring to the free transit that you effectively offer through the tunnel broker; such traffic would otherwise go to AT&T through a transit provider, which may or may not be HE.
My point is that the free transit through tunnel broker and the free transit through an exchange point are roughly equivalent in terms of that driver. Owen
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:mureninc@gmail.com] Sent: Saturday, December 08, 2012 12:46 AM To: nanog@nanog.org 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.
On 12/10/2012 01:27 PM, Schiller, Heather A wrote:
I think most folks would agree that, IPv4 /32 :: IPv6 /128 as IPv4 /29 :: IPv6 /64
Quite the opposite in fact. In IPv6 a /64 is roughly equivalent to a /32 in IPv4. As in, it's the smallest possible assignment that will allow an end-user host to function under normal circumstances. SWIP or rwhois for a /64 seems excessive to me, FWIW. Doug
Quite the opposite in fact. In IPv6 a /64 is roughly equivalent to a /32 in IPv4. As in, it's the smallest possible assignment that will allow an end-user host to >function under normal circumstances.
SWIP or rwhois for a /64 seems excessive to me, FWIW.
IPv4/32 is both a routing endpoint and a host. IPv4 is a 32 bit combined routing and host space. IPv6/64 is a routing endpoint and v6/128 is a host. IPv6 is a 64 bit routing space and also a 64 bit host space for each routing space, not a 128 bit combined routing and host space. Evidently, the whois requirement is for networks, not nodes, which makes sense when you think about how the entity that controls a /64 is assuming responsibility for 2^64 network nodes. -----Original Message----- From: Doug Barton [mailto:dougb@dougbarton.us] Sent: Monday, December 10, 2012 5:05 PM To: Schiller, Heather A Cc: Constantine A. Murenin; nanog@nanog.org Subject: Re: Why do some providers require IPv6 /64 PA space to have public whois? On 12/10/2012 01:27 PM, Schiller, Heather A wrote:
I think most folks would agree that, IPv4 /32 :: IPv6 /128 as IPv4 /29 :: IPv6 /64
Doug ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2793 / Virus Database: 2634/5946 - Release Date: 12/08/12
On Dec 10, 2012, at 2:53 PM, Ian Smith <I.Smith@F5.com> wrote:
Quite the opposite in fact. In IPv6 a /64 is roughly equivalent to a /32 in IPv4. As in, it's the smallest possible assignment that will allow an end-user host to >function under normal circumstances.
SWIP or rwhois for a /64 seems excessive to me, FWIW.
IPv4/32 is both a routing endpoint and a host. IPv4 is a 32 bit combined routing and host space.
IPv6/64 is a routing endpoint and v6/128 is a host. IPv6 is a 64 bit routing space and also a 64 bit host space for each routing space, not a 128 bit combined routing and host space.
You can make a /128 a routing endpoint in IPv6 just like a /32 in IPv4 with all the same rules, restrictions, and limitations.
Evidently, the whois requirement is for networks, not nodes, which makes sense when you think about how the entity that controls a /64 is assuming responsibility for 2^64 network nodes.
Correct (in the first part). In reality, nobody has 2^64 nodes, that's more than the square of the current host addressing available in all of IPv4. You'll never see a /64 full of hosts. For one thing, there's no concept for switching hardware that could handle that large of a MAC adjacency table, nor is there ever likely to be such. Owen
-----Original Message----- From: Doug Barton [mailto:dougb@dougbarton.us] Sent: Monday, December 10, 2012 5:05 PM To: Schiller, Heather A Cc: Constantine A. Murenin; nanog@nanog.org Subject: Re: Why do some providers require IPv6 /64 PA space to have public whois?
On 12/10/2012 01:27 PM, Schiller, Heather A wrote:
I think most folks would agree that, IPv4 /32 :: IPv6 /128 as IPv4 /29 :: IPv6 /64
Doug
----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2793 / Virus Database: 2634/5946 - Release Date: 12/08/12
In message <50C65C84.6080203@dougbarton.us>, Doug Barton writes:
On 12/10/2012 01:27 PM, Schiller, Heather A wrote:
I think most folks would agree that, IPv4 /32 :: IPv6 /128 as IPv4 /29 :: I Pv6 /64
Quite the opposite in fact. In IPv6 a /64 is roughly equivalent to a /32 in IPv4. As in, it's the smallest possible assignment that will allow an end-user host to function under normal circumstances.
SWIP or rwhois for a /64 seems excessive to me, FWIW.
Doug
Even SWIP for a /48 for a residential assignment is excessive. SWIP for a /48 for a commercial assignment is reasonable Note it is the type of assignment, not the size, which is determining factor here. A /64 commercial assignment should have a SWIP entry. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
Sent from my iPad On Dec 10, 2012, at 3:02 PM, Mark Andrews <marka@isc.org> wrote:
In message <50C65C84.6080203@dougbarton.us>, Doug Barton writes:
On 12/10/2012 01:27 PM, Schiller, Heather A wrote:
I think most folks would agree that, IPv4 /32 :: IPv6 /128 as IPv4 /29 :: I Pv6 /64
Quite the opposite in fact. In IPv6 a /64 is roughly equivalent to a /32 in IPv4. As in, it's the smallest possible assignment that will allow an end-user host to function under normal circumstances.
SWIP or rwhois for a /64 seems excessive to me, FWIW.
Doug
Even SWIP for a /48 for a residential assignment is excessive. SWIP for a /48 for a commercial assignment is reasonable
I disagree. SWIP for a /48 with the appropriate notations under residential customer privacy policy provides a good balance between the need for public accountability of resource utilization and privacy concerns for residential customer assignments. Owen
In message <272782D1-8DEA-4718-9429-8B0505DD30BD@delong.com>, Owen DeLong write s:
Sent from my iPad
On Dec 10, 2012, at 3:02 PM, Mark Andrews <marka@isc.org> wrote:
=20 In message <50C65C84.6080203@dougbarton.us>, Doug Barton writes:
On 12/10/2012 01:27 PM, Schiller, Heather A wrote:
I think most folks would agree that, IPv4 /32 :: IPv6 /128 as IPv4 /29 := : I Pv6 /64 =20 Quite the opposite in fact. In IPv6 a /64 is roughly equivalent to a /32 in IPv4. As in, it's the smallest possible assignment that will allow an end-user host to function under normal circumstances. =20 SWIP or rwhois for a /64 seems excessive to me, FWIW. =20 Doug =20 Even SWIP for a /48 for a residential assignment is excessive. SWIP for a /48 for a commercial assignment is reasonable =20
I disagree. SWIP for a /48 with the appropriate notations under residential c = ustomer privacy policy provides a good balance between the need for public a= ccountability of resource utilization and privacy concerns for residential c= ustomer assignments.
Owen
You don't SWIP each residential customer with IPv4. You often SWIP blocks of residential customers down to the pop level. You often SWIP each commercial customer with IPv4. To require a SWIP entry for each residential customer is bureaucracy gone mad. Additionally there is no technical need for this. It isn't needed for address accountability. Residential customers have historically been treated in bulk. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On 10 December 2012 16:07, Mark Andrews <marka@isc.org> wrote:
You don't SWIP each residential customer with IPv4. You often SWIP blocks of residential customers down to the pop level. You often SWIP each commercial customer with IPv4.
To require a SWIP entry for each residential customer is bureaucracy gone mad. Additionally there is no technical need for this. It isn't needed for address accountability. Residential customers have historically been treated in bulk.
Yes, agreed; and note that in my specific case, we're not even talking about the residential customer situation: we're talking about individual private servers (with IPv4) requiring basic IPv6 connectivity (in order to be dual stacked, no more). I'm picky, and will not accept long and unabbreviatable addresses (especially when I'm already paying for a unique and "short" 32-bit IPv4 address). Having my street address, apartment and phone numbers appearing in a public whois is also hardly a pleasantry. But for all I care (and I'm not a network engineer), I just need a single IPv6 address or two; an abbreviatable /124 is all I'd need; but, then, why not just issue a /48, since that's manageable and easier anyways? C.
On Dec 10, 2012, at 4:07 PM, Mark Andrews <marka@isc.org> wrote:
In message <272782D1-8DEA-4718-9429-8B0505DD30BD@delong.com>, Owen DeLong write s:
Sent from my iPad
On Dec 10, 2012, at 3:02 PM, Mark Andrews <marka@isc.org> wrote:
=20 In message <50C65C84.6080203@dougbarton.us>, Doug Barton writes:
On 12/10/2012 01:27 PM, Schiller, Heather A wrote:
I think most folks would agree that, IPv4 /32 :: IPv6 /128 as IPv4 /29 := : I Pv6 /64 =20 Quite the opposite in fact. In IPv6 a /64 is roughly equivalent to a /32 in IPv4. As in, it's the smallest possible assignment that will allow an end-user host to function under normal circumstances. =20 SWIP or rwhois for a /64 seems excessive to me, FWIW. =20 Doug =20 Even SWIP for a /48 for a residential assignment is excessive. SWIP for a /48 for a commercial assignment is reasonable =20
I disagree. SWIP for a /48 with the appropriate notations under residential c = ustomer privacy policy provides a good balance between the need for public a= ccountability of resource utilization and privacy concerns for residential c= ustomer assignments.
Owen
You don't SWIP each residential customer with IPv4. You often SWIP blocks of residential customers down to the pop level. You often SWIP each commercial customer with IPv4.
You SWIP each one that gets a /29 or larger.
To require a SWIP entry for each residential customer is bureaucracy gone mad. Additionally there is no technical need for this. It isn't needed for address accountability. Residential customers have historically been treated in bulk.
It really isn't. We can agree to disagree, as we usually do. It's quite easily automated and it really is the equivalent to current IPv4 policy. The difference being only that in IPv6, we expect more customers to get networks instead of host addresses. Owen
Sent from my iPad On Dec 10, 2012, at 2:04 PM, Doug Barton <dougb@dougbarton.us> wrote:
On 12/10/2012 01:27 PM, Schiller, Heather A wrote:
I think most folks would agree that, IPv4 /32 :: IPv6 /128 as IPv4 /29 :: IPv6 /64
Quite the opposite in fact. In IPv6 a /64 is roughly equivalent to a /32 in IPv4. As in, it's the smallest possible assignment that will allow an end-user host to function under normal circumstances.
No, you could be assigned a /128 and have it function for a single host. However, let's not start doing that as it's pretty brain-dead and the reality is that hardly anyone has a single host any more. Heather has the corollaries correct.
SWIP or rwhois for a /64 seems excessive to me, FWIW.
I'm not sure I disagree, but, I certainly don't feel strongly enough about it to submit a policy proposal. I will say that you are far more likely to get this changed by submitting a policy proposal than you are by complaining to NANOG about it. Owen
On 12/10/2012 03:14 PM, Owen DeLong wrote:
On Dec 10, 2012, at 2:04 PM, Doug Barton <dougb@dougbarton.us> wrote:
On 12/10/2012 01:27 PM, Schiller, Heather A wrote:
I think most folks would agree that, IPv4 /32 :: IPv6 /128 as IPv4 /29 :: IPv6 /64
Quite the opposite in fact. In IPv6 a /64 is roughly equivalent to a /32 in IPv4. As in, it's the smallest possible assignment that will allow an end-user host to function under normal circumstances.
No, you could be assigned a /128 and have it function for a single host.
You saw how I very carefully phrased my statement to try to avoid this kind of ratholing, right? :)
However, let's not start doing that as it's pretty brain-dead and the reality is that hardly anyone has a single host any more.
Heather has the corollaries correct.
You're entitled to your opinion of course, just don't be surprised when people disagree with you.
SWIP or rwhois for a /64 seems excessive to me, FWIW.
I'm not sure I disagree, but, I certainly don't feel strongly enough about it to submit a policy proposal. I will say that you are far more likely to get this changed by submitting a policy proposal than you are by complaining to NANOG about it.
I certainly don't care enough about it to do that, I was just voicing an opinion. Doug (personally I'd be happy just to have native IPv6 available)
On Dec 10, 2012, at 8:35 PM, Doug Barton <dougb@dougbarton.us> wrote:
On 12/10/2012 03:14 PM, Owen DeLong wrote:
On Dec 10, 2012, at 2:04 PM, Doug Barton <dougb@dougbarton.us> wrote:
On 12/10/2012 01:27 PM, Schiller, Heather A wrote:
I think most folks would agree that, IPv4 /32 :: IPv6 /128 as IPv4 /29 :: IPv6 /64
Quite the opposite in fact. In IPv6 a /64 is roughly equivalent to a /32 in IPv4. As in, it's the smallest possible assignment that will allow an end-user host to function under normal circumstances.
No, you could be assigned a /128 and have it function for a single host.
You saw how I very carefully phrased my statement to try to avoid this kind of ratholing, right? :)
However, let's not start doing that as it's pretty brain-dead and the reality is that hardly anyone has a single host any more.
Heather has the corollaries correct.
You're entitled to your opinion of course, just don't be surprised when people disagree with you.
Regardless of how you phrase it, the functional IPv6 equivalent of an IPv4 /32 is an IPv6 /128. You don't configure a /64 on a loopback interface in a router, for example, you configure a /128.
SWIP or rwhois for a /64 seems excessive to me, FWIW.
I'm not sure I disagree, but, I certainly don't feel strongly enough about it to submit a policy proposal. I will say that you are far more likely to get this changed by submitting a policy proposal than you are by complaining to NANOG about it.
I certainly don't care enough about it to do that, I was just voicing an opinion.
Doug (personally I'd be happy just to have native IPv6 available)
I'm loving mine. Owen
IPv4 /32 :: IPv6 /128
i.e. a single host or gkw behind a nat. kinda what i get from comcast and twt now.
IPv4 /29 :: IPv6 /64
i.e. i get a lan segment. makes sense
The minimum assignment requiring a swip is also ensconced in RIR policy.
i am sure that, if you dig deeply enough, a recipe for chocolate chip cookies is ensconced in RIR policy. the bookkeepers drank koolaid and think they have become regulators. does samantha know her mom is a wannabe lawyer? :) randy
On 10 December 2012 13:27, Schiller, Heather A <heather.schiller@verizon.com> wrote:
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?
I think your comparison of IPv4 /32 being equivalent to IPv6 /128 is only true in specific and narrow contexts outside of this discussion, and I strongly disagree with such generalisations being applied here. Just from the practical side and by means of an example, take a look at 6rd and the way other national internet providers have been implementing it. I had a routed /27 with AT&T FTTU; every IPv4 address on AT&T automatically gets a /60 IPv6 allocation; by extension, my IPv4 /27 was equivalent to IPv6 /55 (plus I also must have had one extra /60 for the IPv4 address in the shared subnet to which my /27 IPv4 subnet was routed). And Linode: upon request, they offer a free /56 to any of their customers, to complement a /32 IPv4 allocation. Many other hosting providers likewise provide a free /48 (some do this by default, some upon request) to anyone who only requires a single IPv4 address otherwise. Likewise, HE's tunnelbroker.net gives out a total of five /48's (per a single account) to anyone who asks; and if you look at it, they're still doing this out of the smallest v6 allocation compared to any other carrier: 2001:470::/32; yes, just a /32, when even Linode has a /30. http://bgp.he.net/AS6939#_prefixes6 And the same example is even true of hetzner.de: they assign a /32 IPv4 for free to every server, and the only IPv6 that they give is a /64, offering no other option at all whatsoever (they do offer the option of another, routed IPv6 /64, but that's it). Yet, unfortunately, hetzner.de is one of the few that doesn't offer any IPv6 at all unless you agree for your private data to go to a public database maintained by RIPE when you request any kind of IPv6 connectivity. It presents an obvious barrier to entry, and limits native IPv6 adoption when huge providers like hetzner.de may require you to give up your privacy for native IPv6, but not for IPv4. So, as per above, in my humble view, a /64 IPv6 allocation is equivalent to a NAT in IPv4 terms. :-) Any provider who insists otherwise (especially when it comes down to actually giving out such addresses), simply tries to be creative about their revenue streams in regards to something that's supposed to be a public resource and that's not even that scarce to begin with.
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."
You have conveniently omitted the prior part of the same paragraph about PtP links. https://www.ripe.net/ripe/docs/ripe-553 IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region 21 May 2012 — address policy, ipv4 « 6.2 Network Infrastructure and End User Networks IP addresses used solely for the connection of an End User to a service provider (e.g. point-to-point links) are considered part of the service provider's infrastructure. These addresses do not have to be registered with the End User's contact details but can be registered as part of the service provider's internal infrastructure. 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. » Although written with IPv4 in mind, if you take this paragraph and try to interpret it within IPv6, then the first, non-routed, /64 with hetzner.de can easily be considered a point-to-point link, and due to the plethora of free alternatives people would hardly attempt to use such an allocation in any other way than as indeed a point-to-point link, especially when a second free /64, now routed, is also available. (And even if someone would in fact use their first PtP /64 to create some kind of a VPN and a small home network, then at the internet who-to-blame level how would that be any different whatsoever from them doing a NAT with a /32 IPv4? On the other hand, I do agree that standardised aggregate whois entries detailing the size of individual allocations within a given address space would be very-very useful with IPv6, indeed (else, how do you ban a user by an IP-address?).) Also, consider why so much private information has to be published in whois in the first place: usually, it's for the issues related to network architecture, security, attacks and spam. Why would other network operators benefit from getting information about individual one-person customers of hetzner.de, instead of contact information of hetzner.de themselves? (Or am I really supposed to be getting a phone call at 03:00 in the middle of the night from a random network engineer in another part of the world who decided to visit my private website, and found my individual server misconfigured or inaccessible?) So, in my opinion, in the end, this information about individuals with /64 allocations may only end up being useful for data-miners and potentially copyright trolls. It should not be just optional to not publish such information; it should be specifically prohibited for such information to be published about individual non-company customers (unless the individual explicitly requests for any such information to be published). Many ccTLDs have already stopped providing any kind of information about their Private Person customers (not even a name, nor an email, as a matter of TLD policy).
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?
Thank you for actually looking up the policies; I'll keep this in mind.
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.
What are the exceptions to 6.5.5.1? In other news, Linode has a /30 IPv6 in the US with ARIN, using a /32 for each of their 4 sites within the US (thus already exhausting their original allocation), and it seems like they have absolutely no whois records anywhere (neither for their customers, nor even for their own distinct sites); the only whois you get is for their actual original /30 allocation from ARIN! http://bgp.he.net/net/2600:3c01::/32 -- no individual whois for their Fremont location. For IPv4, they likewise didn't seem to have bothered creating any individual SWIP entries even for each of their own sites (which are all run as separate networks); all their allocations only show their New Jersey address, and, basically, the following comment: Comment: This block is used for static customer allocations. Are they somehow exempt, or are they blatantly violating every ARIN policy imaginable? I also know of at least one other provider who gave me a /48 from their ARIN-issued space without doing any kind of a whois record within their /32, but they have only a single physical site, so it's not such a big deal, IMHO. Also, I notice that your policies at ARIN have exceptions explicitly for Residential Customers, but what about individuals renting network resources in the cloud? Are such individuals suddenly not officially exempt? C.
--Heather
-----Original Message----- From: Constantine A. Murenin [mailto:mureninc@gmail.com] Sent: Saturday, December 08, 2012 12:46 AM To: nanog@nanog.org 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.
participants (16)
-
Constantine A. Murenin -
Dan Luedtke -
Darius Jahandarie -
Doug Barton -
Ian Smith -
Jimmy Hess -
Mark Andrews -
Mikael Abrahamsson -
Owen DeLong -
Patrick W. Gilmore -
Randy Bush -
Ryan Malayter -
Sander Steffann -
Schiller, Heather A -
Siegel, David -
Steve Bertrand