Why do some providers require IPv6 /64 PA space to have public whois?

Mailman List Mirror (Read Only)
1

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. :slight_smile:

Cheers,
Constantine.

2

[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......

3

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

4

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.

5

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

6

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."

7

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.

8

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

9

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. :slight_smile:

C.

10

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.

11

reliable tunnel

bzzzt! oxymoron alert!!!

12

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

13

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.

14

Hi,

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... :frowning:
- Sander

15

> 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... :frowning:

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 :slight_smile:

Steve

16

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?

17

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

18

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.

19

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

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.

SWIP or rwhois for a /64 seems excessive to me, FWIW.

Doug