Re: Why do some providers require IPv6 /64 PA space to have public whois?
On 10 December 2012 13:27, Schiller, Heather A heather.schil...@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 ATT FTTU; every IPv4 address on ATT 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
Re: Why do some providers require IPv6 /64 PA space to have public whois?
On Dec 10, 2012, at 4:07 PM, Mark Andrews ma...@isc.org wrote: In message 272782d1-8dea-4718-9429-8b0505dd3...@delong.com, Owen DeLong write s: Sent from my iPad On Dec 10, 2012, at 3:02 PM, Mark Andrews ma...@isc.org wrote: =20 In message 50c65c84.6080...@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
Re: Why do some providers require IPv6 /64 PA space to have public whois?
On Dec 10, 2012, at 6:53 PM, Constantine A. Murenin muren...@gmail.com wrote: On 8 December 2012 23:10, Owen DeLong o...@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 ATT, 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
Re: Why do some providers require IPv6 /64 PA space to have public whois?
On Dec 10, 2012, at 8:35 PM, Doug Barton do...@dougbarton.us wrote: On 12/10/2012 03:14 PM, Owen DeLong wrote: On Dec 10, 2012, at 2:04 PM, Doug Barton do...@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
RE: Why do some providers require IPv6 /64 PA space to have public whois?
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:muren...@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,
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 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
Re: Why do some providers require IPv6 /64 PA space to have public whois?
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
Re: Why do some providers require IPv6 /64 PA space to have public whois?
In message 50c65c84.6080...@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: ma...@isc.org
Re: Why do some providers require IPv6 /64 PA space to have public whois?
Sent from my iPad On Dec 10, 2012, at 2:04 PM, Doug Barton do...@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
RE: Why do some providers require IPv6 /64 PA space to have public whois?
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:do...@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
Re: Why do some providers require IPv6 /64 PA space to have public whois?
Sent from my iPad On Dec 10, 2012, at 3:02 PM, Mark Andrews ma...@isc.org wrote: In message 50c65c84.6080...@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
Re: Why do some providers require IPv6 /64 PA space to have public whois?
On Dec 10, 2012, at 2:53 PM, Ian Smith i.sm...@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:do...@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
Re: Why do some providers require IPv6 /64 PA space to have public whois?
In message 272782d1-8dea-4718-9429-8b0505dd3...@delong.com, Owen DeLong write s: Sent from my iPad On Dec 10, 2012, at 3:02 PM, Mark Andrews ma...@isc.org wrote: =20 In message 50c65c84.6080...@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: ma...@isc.org
Re: Why do some providers require IPv6 /64 PA space to have public whois?
On 8 December 2012 23:10, Owen DeLong o...@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 ATT, 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 ATT (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 ATT through a transit provider, which may or may not be HE. C.
Re: Why do some providers require IPv6 /64 PA space to have public whois?
On 10 December 2012 16:07, Mark Andrews ma...@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.
Re: Why do some providers require IPv6 /64 PA space to have public whois?
You don't SWIP each residential customer with IPv4. you don't swip anybody. some folk swip each residential customer. randy
Re: Why do some providers require IPv6 /64 PA space to have public whois?
On 12/10/2012 03:14 PM, Owen DeLong wrote: On Dec 10, 2012, at 2:04 PM, Doug Barton do...@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)
Re: Why do some providers require IPv6 /64 PA space to have public whois?
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 Abrahamssonemail: swm...@swm.pp.se
Re: Why do some providers require IPv6 /64 PA space to have public whois?
reliable tunnel bzzzt! oxymoron alert!!!
RE: Why do some providers require IPv6 /64 PA space to have public whois?
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:patr...@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
Re: Why do some providers require IPv6 /64 PA space to have public whois?
On Sat, Dec 8, 2012 at 10:23 PM, Patrick W. Gilmore patr...@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
Re: Why do some providers require IPv6 /64 PA space to have public whois?
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... :-( - Sander
Re: Why do some providers require IPv6 /64 PA space to have public whois?
On Dec 9, 2012, at 2:58 AM, Randy Bush ra...@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?
Re: Why do some providers require IPv6 /64 PA space to have public whois?
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
Re: Why do some providers require IPv6 /64 PA space to have public whois?
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 Abrahamssonemail: swm...@swm.pp.se
RE: Why do some providers require IPv6 /64 PA space to have public whois?
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
Re: Why do some providers require IPv6 /64 PA space to have public whois?
In message CAAAwwbUbWwK09vPfLJ89HyiupP5pP7ZypBhAbM4WMhFHe-=x...@mail.gmail.com, Jimmy Hess writes: On 12/7/12, Constantine A. Murenin muren...@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: ma...@isc.org
Re: Why do some providers require IPv6 /64 PA space to have public whois?
On 8 December 2012 13:03, Mark Andrews ma...@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 ATT (Bay-Area-wise, they still have IPv6 traffic going through their peering in Los Angeles). C.
Re: Why do some providers require IPv6 /64 PA space to have public whois?
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
Re: Why do some providers require IPv6 /64 PA space to have public whois?
On Sat, Dec 8, 2012 at 7:12 PM, Dan Luedtke m...@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
Re: Why do some providers require IPv6 /64 PA space to have public whois?
On Dec 08, 2012, at 21:14 , Darius Jahandarie djahanda...@gmail.com wrote: On Sat, Dec 8, 2012 at 7:12 PM, Dan Luedtke m...@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
Re: Why do some providers require IPv6 /64 PA space to have public whois?
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 ATT (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
Re: Why do some providers require IPv6 /64 PA space to have public whois?
On 8 December 2012 16:12, Dan Luedtke m...@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.
