On 03/22/2014 08:47 AM, Robert Webb wrote:

First, there may be those that do not require IPv6 due to size.

It is a mistake to believe that the only reason to add IPv6 to your network is size. Adding IPv6 to your network _now_ is the right decision because at some point in the not-too-distant future it will be the dominant network technology, and you don't want to get left behind. Doug

On Mar 22, 2014, at 10:16 AM, Nick Hilliard <nick@foobar.org> wrote:

On 22/03/2014 16:29, Doug Barton wrote:

...

It is a mistake to believe that the only reason to add IPv6 to your network is size. Adding IPv6 to your network _now_ is the right decision because at some point in the not-too-distant future it will be the dominant network technology, and you don't want to get left behind.

not wanting to rain on anyone's parade, but people have been claiming this since the days of IPng. Granted, we're a couple of years after IANA runout and two RIRs are also in post-runout phase, but the level of pain associated with continued deployment of ipv4-only services is still nowhere near the point that ipv6 can be considered a viable alternative.

Nick

We've always told everyone the pain would be starting in the runout phase. Not immediately like a wall, but gradually. Some people I know are already experiencing scarcity itches. One or two, some uncomfortable burning sensations. This will ramp up over time. ISPs around you will get their last blocks from ARIN or other RIRs as the last RIRs exhaust soon; then the ISP blocks will be gone. Timescales for each of these phases will be months. There will be M&A or open market recovery of currently unused space for a while longer. With consumers seeing the inevitable slowly increasing markups in price for the new resources. Then the serious global pain starts... It is true that a head in the sand was effective for 15 years. But you'd better pull it out now. Each of these phases is well understood *and we're here now*... -george william herbert george.herbert@gmail.com Sent from Kangphone

On 22/03/2014 18:50, Tore Anderson wrote:

* Nick Hilliard

...

the level of pain associated with continued deployment of ipv4-only services is still nowhere near the point that ipv6 can be considered a viable alternative.

This depends on who you're asking; as a blanket statement it's demonstrably false: For the likes of T-Mobile USA¹ and Facebook², or even myself³, IPv6-only isn't just an «alternative». It's «happening».

FB, T-mobile and you are all using ipv6->ipv4 protocol translators because ipv6-only services are not a viable alternative at the moment. The advantage that using ipv6 gives in these deployment scenarios is that it scales beyond the amount of address space available from rfc1918. As a side effect, it also makes native end-to-end ipv6 connectivity pleasant. Sadly, ipv4 address availability continues to be necessary at the same run rate as before, except in situations where CGN is a possibility. Nick

[1] http://www.dslreports.com/shownews/TMobile-Goes-IPv6-Only-on-Android-44-Devi... [2] https://www.dropbox.com/s/doazzo5ygu3idna/WorldIPv6Congress-IPv6_LH%20v2.pdf [3] http://www.ipspace.net/IPv6-Only_Data_Centers

Tore

On 22/03/2014 19:35, Justin M. Streiner wrote:

CGN also comes with lots of downside that customers are likely to find unpleasant. For some operators, customer (dis)satisfaction might be the driver that ultimately forces them to deploy IPv6.

don't believe for a moment that v6 to v4 protocol translation is any less ugly than CGN. Nick

Le 22/03/2014 23:49, Nick Hilliard a écrit :

On 22/03/2014 19:35, Justin M. Streiner wrote:

...

CGN also comes with lots of downside that customers are likely to find unpleasant. For some operators, customer (dis)satisfaction might be the driver that ultimately forces them to deploy IPv6. don't believe for a moment that v6 to v4 protocol translation is any less ugly than CGN. Shared view. mh

Nick

On Sat, Mar 22, 2014 at 8:19 PM, Randy Bush <randy@psg.com> wrote:

...

don't believe for a moment that v6 to v4 protocol translation is any less ugly than CGN.

it can be stateless

You're smarter than that. -Bill -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004

https://tools.ietf.org/html/rfc6145 https://tools.ietf.org/html/draft-ietf-softwire-map-t-05 https://tools.ietf.org/html/draft-anderson-siit-dc-00

derived from 6346 randy

And all those IPv4 addresses for the 1:1 translation required by the stateless version are coming from where exactly?

maybe you should read the documents

You propose stateless NAT64 as an viable alternative to CGN.

where do i do that?

The question stands: where are you planning to get the extra IPv4 addresses for the static 1:1 mapping?

maybe look at the +P in A+P randy

...

...

You propose stateless NAT64 as an viable alternative to CGN. ^^^ where do i do that? Nick Hilliard

ahh. i see your error. i am not nick hilliard. he's the cute one.

Your reply (verbosity added for clarity): "[Sure it is! Unlike where folks solve their problem with CGN, v6 to v4 protocol translation] can be stateless."

again, you put words in my mouth which were not there. i did not say v6 to v4 translation.

Nah, I'm done following bread crumbs for the day.

cool. then we can all go back to reality and whet people actually said. bye randy

On Mon, Mar 24, 2014 at 8:05 PM, Warren Bailey <wbailey@satelliteintelligencegroup.com> wrote:

FYI He tells everyone they¹re cute. Don¹t buy his tricks, he doesn¹t call back the next morning.

Ps. Take it easy on each other. It¹s the beginning of spring.. Head outside..

Spring!? Snow is in tonight's forecast here in Virginia. Ah well. Ultima Online beckons. It's always spring in Sosaria. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004

On 03/22/2014 10:16 AM, Nick Hilliard wrote:

On 22/03/2014 16:29, Doug Barton wrote:

...

It is a mistake to believe that the only reason to add IPv6 to your network is size. Adding IPv6 to your network _now_ is the right decision because at some point in the not-too-distant future it will be the dominant network technology, and you don't want to get left behind.

not wanting to rain on anyone's parade, but people have been claiming this since the days of IPng.

Hyperbole of the past doesn't negate the reality of the future. :) The IPng folks did a lot of good things, and they made a lot of mistakes. For me personally the "not-to-distant future" part of the above paragraph is new, I have not (until recently) said to people that you'll need IPv6 *soon*, but I have consistently said to people that "You will need IPv6 eventually, so the sooner you start planning for it and moving forward the better off you'll be."

Granted, we're a couple of years after IANA runout and two RIRs are also in post-runout phase,

Another way to say that would be, "Things have been progressing exactly as predicted starting around say, 2005 or so." That's when I first got really enthusiastic about the IPv4 scarcity/promote IPv6 issues. Things have been playing out basically the way that they were predicted to when Tony Hain came to me (when I was IANA manager) with the first draft of his IPv4 runout projections.

but the level of pain associated with continued deployment of ipv4-only services is still nowhere near the point that ipv6 can be considered a viable alternative.

With respect I think you're ignoring some pretty important facts. Not the least of which is the level of pressure that's been taken off of IPv4 runout by the large providers (referenced elsewhere in the thread) who have already moved to IPv6. I think you're also ignoring the fact that at this point unless you can afford to buy substantial address space on the darkish-grey market it's basically impossible to launch a new Internet enterprise of any real scale on IPv4. More importantly I'm confused/dismayed by your language, "still nowhere near the point that ipv6 can be considered a viable alternative." Even though the major content networks already have well-established IPv6 networks, referring to IPv6 as "an alternative" is thinking about the problem in the wrong way. As we all know, phases of technology adoption generally follow this model: All IPv4 Some IPv6, mostly IPv4 Roughly half and half Mostly IPv6, some IPv4 All IPv6 We're still in phase 2 now, but the other phases ARE coming. IPv4 addresses are a finite resource, and as the years go on there will simply not be enough to go around. (Arguably we've already passed that point, but things like CGN are going to let us slide along for a little longer.) So at this point IPv6 is not "an alternative," it's a complement to IPv4. "Doing" IPv6 now means that you'll be ready far in advance of the point when you no longer have a choice. Doug

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 3/23/2014 9:13 AM, Nick Hilliard wrote:

yep, agreed - doing ipv6 now is a sensible business proposition. But it needs to be tempered with the realisation that for nearly all networks, ipv6 is complementary to ipv4 and not a replacement; nor will it become a replacement until the time that people feel that adding A records to their hostnames is unnecessary.

Absolutely concur -- it's a really hard sell to enterprises in the U.S. for any compelling reason, at least right now, why they should take great pains (ad it would be *great* pain) to move to IPv6 while their IPv4 networks work just fine. Also, IPv6 introduces some serious security concerns, and until they are properly addressed, they will be a serious barrier to even considering it. $.02, - - ferg - -- Paul Ferguson VP Threat Intelligence, IID PGP Public Key ID: 0x54DC85B2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlMvCwEACgkQKJasdVTchbJUkwD/eWydkUd7DE7XD9V5ETTENzsa fjuzzOR5l+t/0wE0EPYBANVVCYSBoFA7XeD5twSGDZcO+nvCK6BDwlRju9W+5iH5 =FBBN -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 3/23/2014 2:27 PM, Timothy Morizot wrote:

On Mar 23, 2014 11:27 AM, "Paul Ferguson" <fergdawgster@mykolab.com <mailto:fergdawgster@mykolab.com>> wrote:

...

Also, IPv6 introduces some serious security concerns, and until they are properly addressed, they will be a serious barrier to even considering it.

And that is pure FUD. The sorts of security risks with IPv6 are mostly in the same sorts of categories as those with IPv4 and have appropriate mitigations available. Moreover, by not enabling and controlling IPv6 on their networks, an operator is actually markedly more vulnerable to IPv6 attacks, not less.

Only if end-points are unaware of dual-stack capabilities. Also, neighbor discovery, for example, can be dangerous (admittedly, so can ARP spoofing in IPv4). And aside from the spoofable ability of ND, robust DHCPv6 is needed for enterprises for sheer operational continuity. And that's only a "half" example. I haven't even mentioned spam management in v6, which will become a nightmare if people have been relying on IP BL's or similar. - - ferg - -- Paul Ferguson VP Threat Intelligence, IID PGP Public Key ID: 0x54DC85B2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlMvVfcACgkQKJasdVTchbLv0AEAhd/IkA19ssgDW/R+YDWe6YTQ YRnWIWwiNM+79NuF1EcBAKuMyULkR2hUXdVO7B/IprgpJxrHtzU0mYdTqJJLgnV1 =1iFc -----END PGP SIGNATURE-----

On Mar 24, 2014, at 6:37 AM, Timothy Morizot <tmorizot@gmail.com> wrote:

You'll pardon my skepticism over claims that unspecified security weaknesses make it impossible to do what we have done and are continuing to do.

All this unfilterable ICMP makes for interesting times - I've already run across ND storms caused remotely (deliberately, IMHO). Insane policies such as /64s for p2p link addresses don't help, either. And the consonance of the English letters 'B', 'C', 'D', & 'E' when spoken aloud is quite likely to prove a major security issue, IMHO. Time for folks to adopt the phonetic alphabet, if they absolutely must communicate verbally. IPv6 has all the security issues associated with IPv4, plus a few new ones which are unique to IPv6. Denying the latter doesn't make them go away. ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Luck is the residue of opportunity and design. -- John Milton

On Mon, Mar 24, 2014 at 1:51 AM, Mark Tinka <mark.tinka@seacom.mu> wrote:

On Monday, March 24, 2014 01:37:52 AM Timothy Morizot wrote:

...

Yes. As I said, same general sorts of risks for the most part as in IPv4. Details differ, but same general types. My point was that it's mostly FUD to wave the flag of scary new security weaknesses with no mitigations in IPv6. It's the same general sort of first hop and link security issues that exist in IPv4 with similar mitigations. Not identical, but not radically different or new either.

While the mitigations may not exist yet (like proper firewalls in CPE to protect GUA'ed devices in the home), it still a good idea to bring the risks to light so folk can think about how to get them fixed.

While I don't really disagree with that statement, I'm not entirely sure what CPE firewalls and home devices have to do with enterprise deployments, the topic I was discussing. We've been actively working this for the past three years now and have yet to encounter an IPv6 specific enterprise risk for which no appropriate mitigation exists. That's why I called out the assertion that security weaknesses in IPv6 were *preventing* enterprise deployments as FUD. And until someone specifically names some major unmitigated IPv6-only security weakness blocking enterprise deployment instead of vague hand-waving or lists of security risks (as opposed to weaknesses) with well-defined mitigations, I'll stand by that statement. Scott

On Mar 23, 2014, at 2:45 PM, Paul Ferguson <fergdawgster@mykolab.com> wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

On 3/23/2014 2:27 PM, Timothy Morizot wrote:

...

On Mar 23, 2014 11:27 AM, "Paul Ferguson" <fergdawgster@mykolab.com <mailto:fergdawgster@mykolab.com>> wrote:

...

Also, IPv6 introduces some serious security concerns, and until they are properly addressed, they will be a serious barrier to even considering it.

And that is pure FUD. The sorts of security risks with IPv6 are mostly in the same sorts of categories as those with IPv4 and have appropriate mitigations available. Moreover, by not enabling and controlling IPv6 on their networks, an operator is actually markedly more vulnerable to IPv6 attacks, not less.

Only if end-points are unaware of dual-stack capabilities.

Also, neighbor discovery, for example, can be dangerous (admittedly, so can ARP spoofing in IPv4). And aside from the spoofable ability of ND, robust DHCPv6 is needed for enterprises for sheer operational continuity.

DHCPv6 is no less robust in my experience than DHCPv4. ARP and ND have mostly equivalent issues.

And that's only a "half" example.

I haven't even mentioned spam management in v6, which will become a nightmare if people have been relying on IP BL's or similar.

IP reputation didn’t really scale to IPv4 and was only practical because we were willing to toss out vast swaths of hosts just because they were unfortunately behind the same NATed address as some host that did something wrong some time. So far, it’s proven to be the worst possible solution to SPAM except for all the others. Nonetheless, yes, we’re going to have to come up with a better way in IPv6. OTOH, we will also have better end-to-end accountability in IPv6, so that might actually help make new solutions more feasible. Owen

I can easily answer that one as a holder of v4 space at a commercial entity. The end user does not feel any compelling reason to move to ipv6 if they have enough v4 space. I can't give my employer a solid business case of why they need to make the IPv6 transition. They already hold enough v4 space and are putting more and more servers behind virtual IPs on boxes like the F5 so they are actually gaining on the v4 space issue. They see no economic reason to add an additional layer of complexity to their network where it is already pretty expensive to find savvy staff. Having to find v6 savvy staff is even more challenging. Even if the network guys are up to speed on v6 (admittedly a lot of the junior guys are not) the server and storage guys have a hard time wrapping their minds completely around ipv4. As soon as they see an economic reason to move toward a v6 deployment I am sure they will do so. The major cost is time not money. The engineering staff has quite enough to keep them busy without looking for projects with no ROI for the near future. As soon as ipv6 users cannot reach ipv4 sites, they will need an ipv6 presence. It is very much a chicken and egg problem. Ipv6 users need to reach ipv4 sites and the fact that they can makes it unnecessary for the ipv4 sites move to ipv6. Most commercial entities that are not in the gaming and multimedia do not feel any performance hit on v4 to v6 so there is no current pain point for the current ipv4 holders unless they are experiencing the need for more address space. The commercial users that have been around a long time typically have pretty large allocations (/24 or better) and the majority of them do not need that many public facing addresses. The thing that will push them toward a v6 infrastructure is having most of their customers on ipv6 and their being some performance penalty that they see for being ipv4 only. We are doing some lab testing on v6 and trying to get more experience for the junior guys but there are lots of legacy stuff and lots of old code that is not v6 aware. That stuff is slowly going away but there is no real push for that to happen. Running the v6 infrastructure in parallel with the v4 infrastructure does not gain anyone very much, unfortunately they will have to run in parallel for quite some time. Another issue is having all of their global MPLS carriers and Internet service providers supplying dual stack capability on those circuits. There is just not enough v6 traffic to make the case for dedicated access circuits supporting just ipv6. Steven Naslund Chicago IL

...

It is unsettling to see such dismissive attitudes.

...

I'll leave it as an exercise for the remainder of... everywhere to figure out why there is resistance to v6 migration, and it isn't "just because" people can't be bothered.

...

Your customers are your compasses. And as Randy Bush always like to say (paraphrased), "I encourage my competitors to dismiss customer concerns over IPv6 migration."

I'll leave it as an exercise for the remainder of... everywhere to figure out why there is resistance to v6 migration, and it isn't "just because" people can't be bothered. I'm sure there are numerous enterprises in the same shape I am in, with significant equipment investment in non-quite-ipv6-ready gear, and insufficient technology refresh capex monies to get ipv6-ready capacity-equivalent replacements. Cisco 6500/7600 even with Sup720 has issues, and I know of a number of networks still running Sup2 on 6500/7600 or even older (including some gear in my own network, where I still have old gear, older even than I'm willing to admit publicly, serving in core roles; I just decommissioned a failing Extreme Summit 1i

On 03/24/2014 09:39 PM, Paul Ferguson wrote: this past Saturday, and still have two more in core roles, doing Layer 3 IPv4 in one case). I know I'm not alone. While much of this gear may be fully depreciated, the cost of the forklift upgrade is major, and the gear is not the biggest part of the cost. Repairs are not anywhere near as draining on the capex budget as complete chassis upgrades are, and so we keep old gear running because it's what we can afford to do. So capex is a big part of it; but then there's training costs and the opex of dealing with a new-to-us technology. Just my very-late-to-the-party opinion, and not likely to change anything at all, but in hindsight it seems we might have been better off with ipv4.1 instead of ipv6, which, IMO, just simply bit off too much in one bite. Much like how the Fountainhead project at DG got eclipsed by the much less ambitious Eagle, and never really went anywhere due to its pie-in-the-sky goals, when all the customers really wanted was a 32-bit Eclipse, which Eagle provided. (Tracy Kidder, "The Soul of a New Machine" which should be on every tech's must-read list). Yeah, I know, too late to matter, as ipv6 is here and here to stay. But the transition could have been smoother and less traumatic to equipment vendors' customers. At least that's my opinion and experience, your mileage may vary.

On 3/26/2014 12:55 PM, Luke S. Crawford wrote:

However, DHCPv6 isn't anywhere near as useful for me, as someone who normally deals with IPs that don't change, as DHCPv4 is.

My favorite is the RA thing. Years ago I decided that stupid DSLAMs were better than smart ones, so I generally utilize 1 vlan per customer with q-in-q and let the router handle all security. This meant I didn't have the usual breakage smart DSLAMs had with IPv6. Ideally, the router would run passive and not send regular RA updates. However, that isn't always viable with all clients. Sending out regular announcements and replicating them to all the vlans is extremely inefficient. Jack

On Wed, Mar 26, 2014 at 10:55:03AM -0700, Luke S. Crawford wrote:

There are many ways to skin this cat; stateless autoconfig looks like it mostly works, but privacy extensions seem to be the default in many places; outgoing IPv6 from those random addresses will trip my BCP38 filters.

Your what-now? You do realise SLAAC works entirely within a single /64, which shouldn't be difficult to decide is either routable or not in one hit, right? - Matt -- Q: Why do Marxists only drink herbal tea? A: Because proper tea is theft. -- Chris Suslowicz, in the Monastery

On Mar 26, 2014 6:27 PM, "Luke S. Crawford" <lsc@prgmr.com> wrote:

My original comment and complaint, though, was in response to the assertion that DHCPv6 is as robust as DHCPv4. My point is that DHCPv6 does not fill the role that DHCPv4 fills, if you care about tying an IP to a MAC and you want that connection to persist across OS installs by customers.

You're right. DHCPv6 is more robust than DHCPv4. At least those of us in the enterprise space appreciate a client identifier that doesn't change when the hardware changes. And v6 doesn't work the same as v4 so you will expend more effort trying to force it to fit a v4 model. Scott

On Mar 26, 2014, at 5:50 PM, Chuck Anderson <cra@WPI.EDU> wrote:

On Wed, Mar 26, 2014 at 06:52:53PM -0500, Timothy Morizot wrote:

...

On Mar 26, 2014 6:27 PM, "Luke S. Crawford" <lsc@prgmr.com> wrote:

...

My original comment and complaint, though, was in response to the assertion that DHCPv6 is as robust as DHCPv4. My point is that DHCPv6 does not fill the role that DHCPv4 fills, if you care about tying an IP to a MAC and you want that connection to persist across OS installs by customers.

You're right. DHCPv6 is more robust than DHCPv4. At least those of us in the enterprise space appreciate a client identifier that doesn't change when the hardware changes.

No, it is LESS robust, because the client identifier changes when the SOFTWARE changes. Around here, software changes MUCH more often than hardware. Heck, even a dual-boot scenario breaks the client identifier stability. Worse yet, DHCPv6 has created a scenario where a client's IPv4 connectivity and IPv6 connectivity break under /different/ scenarios, causing difficult-to-troubleshoot half-connectivity issues when either the hardware is replaced or the software is reloaded.

Any client whose DUID changes on software re-install has a very poor choice of default DUID and should be configurable for a better choice of DUID. That is not DHCPv6’s fault. DHCPv6 is perfectly capable of behaving as you wish. Blaming the protocol for poor implementation choices by your (or your client’s) vendors is a little odd in my opinion. Owen

It is reality. DHCPv6 needs to take reality into account.

One modest attempt to do so is dhcpy6d at https://dhcpy6d.ifw-dresden.de. Still work in progress and might not fit into every environment but helps some others. Regards -- Henri Wahl IT Department Leibniz-Institut fuer Festkoerper- u. Werkstoffforschung Dresden tel: (03 51) 46 59 - 797 email: h.wahl@ifw-dresden.de http://www.ifw-dresden.de Nagios status monitor Nagstamon: http://nagstamon.ifw-dresden.de DHCPv6 server dhcpy6d: http://dhcpy6d.ifw-dresden.de IFW Dresden e.V., Helmholtzstrasse 20, D-01069 Dresden VR Dresden Nr. 1369 Vorstand: Prof. Dr. Juergen Eckert, Dr. h.c. Dipl.-Finw. Rolf Pfrengle -- Henri Wahl IT Department Leibniz-Institut fuer Festkoerper- u. Werkstoffforschung Dresden tel: (03 51) 46 59 - 797 email: h.wahl@ifw-dresden.de http://www.ifw-dresden.de Nagios status monitor Nagstamon: http://nagstamon.ifw-dresden.de DHCPv6 server dhcpy6d: http://dhcpy6d.ifw-dresden.de IFW Dresden e.V., Helmholtzstrasse 20, D-01069 Dresden VR Dresden Nr. 1369 Vorstand: Prof. Dr. Juergen Eckert, Dr. h.c. Dipl.-Finw. Rolf Pfrengle

...

DHCPv6 as defined in RFC 3315 does not offer client MAC address at all (thus making the job more difficult for a number of organizations).

Yes it does…

What do you think “Link Layer Address” (RFC 3315, Section 9.1 Type 3) is? From RFC-3315 Section 9.4, it seems pretty clear that is exactly what this is intended to be. True, it includes an additional 16 bits of

...

media type,

- I cannot a priori know which DUID type a particular client will use. Of the three DUID types in RFC 3315 section 9.1, type 1 and 3 include link layer address while type 2 does not. - As has already been pointed out, the same physical hardware may use different DUID types when booted with different operating systems. - The language in RFC 3315 is pretty explicit in saying that a server *must* treat the DUID as an opaque value - in other words, you are not allowed to "inspect" it in any way to find the presumed MAC address and take any action based on the MAC address.

...

All I've seen so far indicates that this was a deliberate choice by the DHCPv6 designers, and in my opinion a very poor one. Fortunately we now have RFC 6939 (DHCPv6 Client Link-Layer Address Option), and we're waiting for vendors to implement this. That solves one half of the problem.

Yes and no.

At the time RFC3315 was written, network cards changed independent of motherboards on a regular basis and this fact was a source of great consternation for DHCPv4 operators. Over time, that changed AFTER RFC3315 was written, but if you read section 9.4, it seems pretty clear that this change was anticipated by the authors and that DUID-LL was intended for the situation we have today.

I think understand the well-meant intentions of the RFC 3315 authors. However, my claim is that the actual end result for IPv6 leaves us in a *worse* situation than for IPv4. And one which, among others, makes it very difficult to correlate IPv4 and IPv6 leases (something which I have no need for today, but which I could easily see a need for in the future). Steinar Haug, Nethelp consulting, sthaug@nethelp.no

On Mar 27, 2014, at 1:55 PM, Karl Auer <kauer@biplane.com.au> wrote:

On Thu, 2014-03-27 at 05:34 -0700, Owen DeLong wrote:

...

What do you think “Link Layer Address” (RFC 3315, Section 9.1 Type 3) is? From RFC-3315 Section 9.4, it seems pretty clear that is exactly what this is intended to be. True, it includes an additional 16 bits of media type, but I don’t see that as being a problem.

Though to be fair 3315 also says that the DUID should be treated as an opaque blob, not parsed and bits extracted from it. From section 9:

"Clients and servers MUST treat DUIDs as opaque values and MUST only compare DUIDs for equality. Clients and servers MUST NOT in any other way interpret DUIDs."

Regarding section 9.4, which you refer to: 3315 only uses MACs to *construct* useful DUIDs, not as a means of communicating MACs to clients or servers. Also, an operator cannot RELY on getting a MAC address in a DUID.

DUID's *are* different and *do* require new ways of doing things. People will work it out.

Right… The comment wasn’t about getting the Mac address, the comment was about having a DUID that remains the same across reboots and software installations. Using LL (type 3) DUIDs should accomplish that. Linking your IPv4 DHCP System ID and your IPv6 DHCP System ID is a completely different problem which I don’t see much practical purpose for other than by the hostname which could easily be handled in the DDNS registration process. Owen

On 03/26/2014 11:14 PM, Owen DeLong wrote:

Why not just use private VLAN layer 2 controls for the privacy you describe?

The technology I know of is what cisco calls 'protected ports' - My understanding is that those simply mean you can't pass traffic to or from other 'protected ports' - I use that capability when, say, putting a bunch of IPMIs on a private network, it works great, as if one of the IPMI ports is trying to talk to another, something is very wrong and it gets blocked. They are commonly used in the dedicated server hosting world to do what you are describing, but they have a big downside when being used on the public side; customer 1 can't talk to customer 2. Now, this isn't usually a big deal, except in one very common case; what if one entity buys two hosts? now those two hosts can't talk to oneanother. This is a very common problem for dedicated hosting providers (and why I give my dedicated hosts a vlan and a routed subnet, wasting IPv4.) For my virtuals, though, I have a much more clever "switch" as it's just some software running in the Dom0, so at least in the IPv4 world, filtering just their /32 in and out is a much better solution.

Yes, you risk customer A spoofing customer B, but is that really a problem in your environment? Really? If so, one could argue you might want to consider getting a better class of customers.

You wouldn't feel uncomfortable if some other company could come in and not only spoof your IP, but receive the return traffic? Keep in mind that they could do this in a way that is quite difficult to detect or trace, if they were clever about it. I may trust my provider, to a certain extent, but I certainly don't trust everyone who gives my provider money.

On Mar 26, 2014, at 10:55 AM, Luke S. Crawford <lsc@prgmr.com> wrote:

On 03/24/2014 06:18 PM, Owen DeLong wrote:

...

DHCPv6 is no less robust in my experience than DHCPv4.

ARP and ND have mostly equivalent issues.

This depends a lot on what you mean by 'robust'

Now, I have dealt with NAT, and I see IPv6 as a technology with the potential to make my life less unpleasant. I really want IPv6 to succeed.

However, DHCPv6 isn't anywhere near as useful for me, as someone who normally deals with IPs that don't change, as DHCPv4 is.

With DHCPv4, my customers all get an address based on their mac that doesn't change if their box is re-installed. I configure this on the DHCP server, and the customer can run whatever dhcp client they like on whatever OS they like and they get the same IP every time.

Other than it being based on DUID instead of MAC (which, btw, DUID can be based on MAC), this is also possible in DHCP6.

With DHCPv6 there is a time-based identifier that is added to the mac that makes it impossible, as far as I can tell, to give the customer a consistent IP across OS wipes without doing significant client configuration.

Nope. Not true.

There are many ways to skin this cat; stateless autoconfig looks like it mostly works, but privacy extensions seem to be the default in many places; outgoing IPv6 from those random addresses will trip my BCP38 filters. That, and reading the standard, it sure doesn't sound like consistency was a goal, even though it seems fairly consistent experimentally. there's a lot of "generally" and "may" in the text about what it adds to the mac in order to get the local identifier.

Why would your BCP38 filters be filtering down below the prefix level? The random addresses all still have the same 64 bit prefix. For non-privacy addresses, it’s very clear… 64 bit mac is just used. 48 bit mac is OR’d with 0x0200 0000 0000 and then split at the OUI/ESI boundary (24 bits) where 0xfffe is inserted. Thus 1234.5678.abcd would become 1234.56ff.fe78.abcd and 0123.4567.89ab would become 0323.45ff.fe67.89ab. For privacy addresses, this is kind of all over the map and multiple different algorithms with different entropic properties are proposed. Worse, Micr0$0ft doesn’t conform to the standard at all and, instead, uses no entropy to provide an address that is different per prefix, but the same every time for the same prefix.

It might make sense to just give everyone their own vlan and their own /64; that would, of course, bring its own problems and complexities (namely that I've gotta have the capability to deal with more customers than I can have native vlans - not impossible to get around, but significant added complexity.)

I don’t see the point of that.

I suppose I can also just keep DHCPv4 around, and if folks want IPv6, well, they have to wire down the address themselves. That's how I'm doing it now.

That seems unnecessarily difficult. Owen

On Sun, Mar 23, 2014 at 04:27:16PM -0500, Timothy Morizot wrote:

On Mar 23, 2014 11:27 AM, "Paul Ferguson" <fergdawgster@mykolab.com> wrote:

...

Also, IPv6 introduces some serious security concerns, and until they are properly addressed, they will be a serious barrier to even considering it.

And that is pure FUD. The sorts of security risks with IPv6 are mostly in the same sorts of categories as those with IPv4 and have appropriate mitigations available. Moreover, by not enabling and controlling IPv6 on their networks, an operator is actually markedly more vulnerable to IPv6 attacks, not less.

Scott

Yo, Tim/Scott. Seems you have not been keeping up. http://go6.si/wp-content/uploads/2011/11/DREN-6-Slo-IPv6Summit-2011.pdf points out several unique problems w/ IPv6 and in deployments where there are ZERO IPv4 equivalents. Ferg is paranoid, but it doesn;t mean they are not out to get him/IPv6. /bill

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 3/23/2014 3:56 PM, Timothy Morizot wrote:

My comments represent reality. Your security posture is much worse in an IPv4 only configuration than if you enable and control IPv6.

Says you. On the other hand, there are beaucoup enterprise networks unwilling to consider to moving to v6 until there are management, control, administrative, and security issues addressed. You can continue to deride our issues, and make derisive comments until your heart's content, but it does not change reality. And on that, it will be the last I say on the matter on NANOG. Best & Cheers, - - ferg - -- Paul Ferguson VP Threat Intelligence, IID PGP Public Key ID: 0x54DC85B2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlMvbI4ACgkQKJasdVTchbK0igD+JF+M3DRoRz5wIJFo+tLV5dFF KuoOPKOQYJ8Vpf32aMsA/2ccs9CDrbq5hatw+LkL8/CHafTbOWGkhdYfjv7Q6ghM =HeCa -----END PGP SIGNATURE-----

"I wasn't aware that calling out FUD was derisive, but whatever." It's derisive because you completely dismiss a huge security issue that, given the state of IPv6 adoption, a great majority of companies are facing. Calling it FUD is completely wrong because it *is* a legitimate security issue for most businesses. Sure, you've got the few who have been able to properly plan for and secure their networks against the increased attack surface of IPv6, but again...most companies haven't. Slinging false proclamations of FUD is as harmful as FUD itself. On Sun, Mar 23, 2014 at 4:49 PM, Timothy Morizot <tmorizot@gmail.com> wrote:

On Mar 23, 2014 6:21 PM, "Paul Ferguson" <fergdawgster@mykolab.com> wrote:

...

Says you.

And many others. My comments were actually reiterating what I commonly see presented today.

...

On the other hand, there are beaucoup enterprise networks unwilling to consider to moving to v6 until there are management, control, administrative, and security issues addressed.

Whereas there are other enterprise networks, including mine, who are actively deploying IPv6 and have been for a number of years now. So unless you can come up with something truly novel that we haven't already dealt with, I'll stick by my use of FUD.

...

You can continue to deride our issues, and make derisive comments until your heart's content, but it does not change reality.

I wasn't aware that calling out FUD was derisive, but whatever.

Cheers,

Scott

-- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0

"unless by few you simply mean a minority" Which I do. "appropriately mitigating the security risks shows the claim that there are security weaknesses in IPv6 preventing its adoption is false." No. It doesn't. It's not the sole reason, but it's a huge factor to consider. "But there's nothing inherent to IPv6 stopping them." There is because it doubles your attack surface at the very least. At the worst, it increases it exponentially since suddenly all your internal devices (that were never configured to be public-facing) are suddenly accessible from everywhere. None of this isn't preventable, by the way. There are a myriad of solutions that can and do mitigate these risks. But to simply dismiss the security considerations is, I think, incredibly naïve and unrealistic. On Sun, Mar 23, 2014 at 5:41 PM, Timothy Morizot <tmorizot@gmail.com> wrote:

On Mar 23, 2014 7:24 PM, "Mike Hale" <eyeronic.design@gmail.com> wrote:

...

It's derisive because you completely dismiss a huge security issue that, given the state of IPv6 adoption, a great majority of companies are facing.

The original assertion was that there are unaddressed security weaknesses in IPv6 itself preventing its adoption. At least that's the way I read it. And that assertion is mostly FUD.

...

Calling it FUD is completely wrong because it *is* a legitimate security issue for most businesses. Sure, you've got the few who have been able to properly plan for and secure their networks against the increased attack surface of IPv6, but again...most companies haven't.

Well, it's hardly a few at this point, unless by few you simply mean a minority. But it's a numerous and growing minority. Moreover, the acknowledgement that enterprises have been able to properly plan and deploy IPv6 while appropriately mitigating the security risks shows the claim that there are security weaknesses in IPv6 preventing its adoption is false.

Now admittedly if an enterprise hasn't done any security planning or assessments then they aren't ready to deploy IPv6. But there's nothing inherent to IPv6 stopping them.

Scott

-- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0

[] It seems to me that the only thing that really matters in v6 wars for enterprise is whether their content side has a v6 face. Who really cares whether they migrate away from v4 so long as they make their outward facing content (eg web, etc) available over v6? That's really the key. Mike

"then there aren't any inherent security weaknesses preventing its adoption by enterprises." You're right. There's not an inherent security weakness in the protocol. The increased risk is due to the increase in your attack surface (IMHO). "Your attack surface has already expanded whether or not you deploy IPv6." Not so. If I don't enable IPv6 on my hosts, the attacker can yammer away via IPv6 all day long with no result. "And if an enterprise doesn't have firewalls in place, then their devices are already accessible." For those devices that have publicly routable IP addresses, sure. "My organization is particularly strict at our perimeter" Then sir, you're in a fortunate and small group. "I've simply pointed out that it really isn't any harder to plan and manage for v6 than for v4" Except it is. I get your point that there aren't any additional vulnerabilities in v6 than they are in v4. My point is that it's a lot more work. And as someone who's facing this issue right now, I promise you...it's a lot more work. I'm not saying it's not worth the effort nor that it's unnecessary...but to imply that securing v6 is an easy step up from securing v4 is inaccurate. "Simply pretending that if you don't enable IPv6, you're somehow immune from IPv6 threats is naïve." No. If I turn off v6 in my kernel, I am absolutely immune from native v6 threats. I'm happy to be proven wrong if you can show me a case where this isn't so. Mark: Everything you've said is correct. But my point is simply that there *are* security considerations when deploying v6, and they're bigger than some rare and esoteric bug that's only exploitable when all the stars align. With v6, a simple misconfiguration can open up every single host directly to the outside. The same simply isn't true with NAT where you have to explicitly define inbound rules. Again...I'm not saying these considerations are insurmountable. I'm not saying you shouldn't deploy v6 because of potential security holes. But to sound dismissive of those security considerations involved with deploying v6 is very counterproductive. On Sun, Mar 23, 2014 at 6:25 PM, Timothy Morizot <tmorizot@gmail.com> wrote:

On Mar 23, 2014 7:54 PM, "Mike Hale" <eyeronic.design@gmail.com> wrote:

...

"unless by few you simply mean a minority" Which I do.

Then that's fine. But there are numerous enterprises in that minority and it includes some pretty large enterprises. My own enterprise organization has more than 600 sites, 100k employees, and thousands of contractors.

...

"appropriately mitigating the security risks shows the claim that there are security weaknesses in IPv6 preventing its adoption is false." No. It doesn't. It's not the sole reason, but it's a huge factor to consider.

Logic 101? If security-conscious enterprises have successfully implemented IPv6 while mitigating the security risks, then there aren't any inherent security weaknesses preventing its adoption by enterprises. A non-FUD statement would be that we've assessed our infrastructure and preparedness for IPv6 and aren't yet in a position where we can safely deploy IPv6. A FUD statement is the assertion that there are inherent security weaknesses in the protocol preventing enterprises from deploying it.

...

There is because it doubles your attack surface at the very least. At the worst, it increases it exponentially since suddenly all your internal devices (that were never configured to be public-facing) are suddenly accessible from everywhere.

It's an IPv6 world. Your attack surface has already expanded whether or not you deploy IPv6. In fact, an enterprise will be making itself increasingly vulnerable to IPv6 attacks by refusing to deploy it than by securely enabling and controlling the protocol.

And if an enterprise doesn't have firewalls in place, then their devices are already accessible. NAT44 doesn't provide any meaningful security protection. If you have firewalls with appropriate policies, then it's silly to claim your internal devices are suddenly accessible from everywhere. My organization is particularly strict at our perimeter. Everything is default deny in both directions for both protocols and we very carefully open holes. We also allow very little unproxied access to the Internet. (DNS, SMTP, and HTTP/HTTPS being the most common services provided in our Internet access points.)

...

None of this isn't preventable, by the way. There are a myriad of solutions that can and do mitigate these risks. But to simply dismiss the security considerations is, I think, incredibly naïve and unrealistic.

Nowhere have I dismissed security considerations for either IPv4 or IPv6. I've simply pointed out that it really isn't any harder to plan and manage for v6 than for v4. And we currently live in a dual-protocol Internet. Simply pretending that if you don't enable IPv6, you're somehow immune from IPv6 threats is naive.

Scott

-- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0

I am not sure I agree with the basic premise here. NAT or Private addressing does not equal security. A globally routable address does not necessarily mean globally accessible. Any enterprise that cares a wit about network security is going to have a firewall. If you are relying on NAT to protect hosts that have private addresses then you are already in a world of hurt so it won't matter much that IPv6 increases your attack surface because it is already pretty weak. In fact the enterprises running v4 better worry there first. They don't have to worry about the v6 stack too much because their network is not routing v6 yet so are only vulnerable within the network borders or subnets. I think even residential users mostly know that a private address does not make you safe. The same tools that protect your v4 machine are still necessary to protect a v6 machine. In fact, just because I have an IPv6 allocation does not mean I have to allow the world to route to them. There is no reason that a proxy cannot be used on the v6 space you have internally and there is no reason I can't point an entire address range at the outside interface of my firewall. The only difference here is that my firewall no longer has to NAT addresses. Thinking of NAT as a security mechanism is not viable for either address space. An enterprise with a respectable firewall can easily choose to allow or disallow access to any range of addresses that they wish so I don't see much difference between IPv6 and IPv4. I would think in most enterprise models you would have a group of addresses that can be reached from the outside world according to some policy (the DMZ or public NATs in v4 world) and the remainder only have access outbound according to policy (your private space behind your NAT v4 addresses in that world). I don't see how v6 massively changes things for the enterprise and the residential user can easily be protected behind a simple consumer firewall. As far as printers being a more dangerous attack vector than computers, I definitely don't buy that argument. It does not change in v4 or v6. Assuming that both stacks are vulnerable to attack I would be less worried about the printer because I am not aware of any of my printers running malware in v4. I think the PC platform being much more complex and having many more interfaces for active programming like DLLs, Java, ActiveX, etc, are much more the threat. I personally have not seen a DDoS attack launched by printers (they may exist but I am not aware of them). If I was going to design an attack for a printer, I would think that data theft would be the most dangerous. I have wondered about multifunction printers emailing print data to someone but I have never seen that yet. Steven Naslund Chicago IL On Mar 23, 2014 8:44 PM, "Mike Hale" <eyeronic.design@gmail.com> wrote:

"Your attack surface has already expanded whether or not you deploy IPv6." Not so. If I don't enable IPv6 on my hosts, the attacker can yammer away via IPv6 all day long with no result. .

not to mention the cost in readdressing your entire network when you change an upstream provider. Nat was a fix to a problem of lack of addresses, however, the use of private address space 10/8, 192.168/16 has allowed many to enjoy a simple network addressing scheme. I have and will continue to deploy IPV6, however the ease and simplicity of IPv4 cannot and should not be overlooked. Ipv6 requires a complete reeducation of they way we look at routing and the core of the network. I will not be trolling here, I prefer to troll off the Florida straits for large fish instead. .. -------- Original message -------- From: William Herrin Date:03/24/2014 12:27 PM (GMT-05:00) To: "Naslund, Steve" Cc: NANOG list Subject: Re: misunderstanding scale On Sun, Mar 23, 2014 at 11:07 PM, Naslund, Steve <SNaslund@medline.com> wrote:

I am not sure I agree with the basic premise here. NAT or Private addressing does not equal security.

Hi Steve, It is your privilege to believe this and to practice it in the networks you operate. Many of the folks you would have deploy IPv6 do not agree. They take comfort in the mathematical impossibility of addressing an internal host from an outside packet that is not part of an ongoing session. These folks find that address-overloaded NAT provides a valuable additional layer of security. Some folks WANT to segregate their networks from the Internet via a general-protocol transparent proxy. They've had this capability with IPv4 for 20 years. IPv6 poorly addresses their requirement. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004

I doubt that many residential customers will be readdressing their networks except for us geeks. Most of them are going to be using CPE that grabs an address via DHCP for the WAN interface and then does an IPv6 DHCP PD with the /64 it gets from the service provider. The customer sees nothing at all. It is plug and play. In IPv6 the concept of manual addressing is strongly discouraged so the issue of readdressing networks should be improved not made more difficult. Private address space assignments might be simple to you but grandma and my sister in law, not so much. They just plug in their gear and don't worry about addresses. In the corporate world, there is nothing stopping you from keeping your ipv4 private addressing going for a long time. In fact, I think that is what most companies will do. If you want IPv6 internally, then have at it and please use DHCP. Steven Naslund

On Mon, Mar 24, 2014 at 11:36 AM, Alexander Lopez <alex.lopez@opsys.com<mailto:alex.lopez@opsys.com>> wrote: not to mention the cost in readdressing your entire network when you change an upstream provider.

Nat was a fix to a problem of lack of addresses, however, the use of private address space 10/8, 192.168/16 has allowed many to enjoy a simple network addressing scheme.

Which is, of course, precisely the use case that ULA and NPTv6 (RFC 6296, not to be confused with a non-existent NAT66) addresses....

On Mar 24, 2014, at 9:36 AM, Alexander Lopez <alex.lopez@opsys.com> wrote:

...

not to mention the cost in readdressing your entire network when you change an upstream provider.

Nat was a fix to a problem of lack of addresses, however, the use of private address space 10/8, 192.168/16 has allowed many to enjoy a simple network addressing scheme.

This is easily and better solved in IPv6 using provider independent addressing which is readily available. <rant> Yes but the number of people needing just a /64 will far outnumber the one requesting a /48.

I would say that the majority of users today and for the future will not require a /48, but will simply use the allocation given to them by their upstream. Many today do not multi-home and how many SMB customers just use a single Public IP behind a NAT device? It is easy for us on this list to use or request PIA, but what about the 10 person office? It is late and I am just rambling, but even with DHCP(4and6) changing IP networks is not a trivial thing. Not hard, but it will require a lot more planning than what many do today of simply changing the WAN IP address and some records in the DNS (if needed) <OldGuyComplainingAboutHowGoodThingsWereBackInTheDay> I am not saying anything that is new to members of this group, I guess I am just venting a bit of frustration. </OldGuyComplainingAboutHowGoodThingsWereBackInTheDay> </rant>

...

Ipv6 requires a complete reeducation of they way we look at routing and the core of the network.

I wouldn't say complete, but significant.

Owen

On Tue, 25 Mar 2014 16:31:17 +1100, Mark Andrews said:

My bet is the number needing more that a single /64 will exceed the number needing just a /64. Most phones really need two /64 for tethering and currently there are lots of kludges to work around only one being available.

As a data point, cerowrt (an openwrt fork) will ask upstream for a /60 or /56 via dhcp-pd, and then burn a /64 for each logical subnet. On a WNDR3800, it can burn 9 /64s out of the box, and more if you start doing VLAN stuff...

It is late and I am just rambling, but even with DHCP(4and6) changing IP networks is not a trivial thing. Not hard, but it will require a lot more planning than what many do today of simply changing the WAN IP address and some records in the DNS (if needed)

We tried: http://tools.ietf.org/wg/6renum In particular, you may want to read http://tools.ietf.org/html/rfc6879 when planning and renumbering IPv6; it's intended to save you pain later. Lee

On Mon, Mar 24, 2014 at 1:05 PM, Patrick W. Gilmore <patrick@ianai.net> wrote:

On Mar 24, 2014, at 12:21, William Herrin <bill@herrin.us> wrote:

...

Some folks WANT to segregate their networks from the Internet via a general-protocol transparent proxy. They've had this capability with IPv4 for 20 years. IPv6 poorly addresses their requirement.

NAT i s not required for the above. Any firewall can stop incoming packets unless they are part of an established session. NAT doesn't add much of anything, especially given that you can have one-to-one NAT.

Hi Patrick, What sort of traction are you getting from that argument with enterprise security folks who object to deploying IPv6 because of NAT? Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004

On Mar 24, 2014, at 5:05 PM, "Patrick W. Gilmore" <patrick@ianai.net> wrote:

On Mar 24, 2014, at 12:21, William Herrin <bill@herrin.us> wrote:

...

On Sun, Mar 23, 2014 at 11:07 PM, Naslund, Steve <SNaslund@medline.com> wrote:

...

...

I am not sure I agree with the basic premise here. NAT or Private addressing does not equal security.

...

Many of the folks you would have deploy IPv6 do not agree. They take comfort in the mathematical impossibility of addressing an internal host from an outside packet that is not part of an ongoing session. These folks find that address-overloaded NAT provides a valuable additional layer of security.

Some folks WANT to segregate their networks from the Internet via a general-protocol transparent proxy. They've had this capability with IPv4 for 20 years. IPv6 poorly addresses their requirement.

It's unfortunate that it is the way it is, but many enterprise people have this ingrained in them - they don't want to be connected to the internet except for a few exceptions. Just the fact that they can't ping their machines gives them a warm and fuzzy. In a run-of-the-mill default NAT setup, you can deploy a network printer with no security and nobody from the internet can print to it. It's default deny, even without setting anything else up, by virtue of not being on the internet and not having an address. I know there are ways to subvert a NAT but that applies to perimeter and host firewalls too. IPv6 global numbers are great for those of us that actually want to connect to the internet, but enterprise people with rfc1918 numbering have gotten used to being disconnected, and while most of us know that it's trivial to firewall IPv6, it's still a big jump from using a NAT/proxy to being 'on the internet'. It's even more complex if it's only halfway and there are two different protocols to manage. People will always resist change, and in this case, why should they change when it's only going to make their job harder? Makes sense to me, but I wish it weren't that way. They will probably just find ways to proxy and NAT IPv6 too, so that it fits the IPv4 model with 'private' addresses. Just look at what's been happening with UDP floods. It's scared people enough that some are just blocking certain UDP ports or UDP completely. I imagine we will soon see some big IPv6 specific attacks that result in crashing hosts/routers, and that will just make people resist it harder, because why would they want that headache? I think in a lot of situations, unless their business is networking specifically, the network is considered good enough if you can browse (most) webpages. For IPv6 only sites, that could be accomplished with a web proxy setting on all the desktops. It's not really right, it's inefficient, error prone and bunch of other things, but that doesn't mean people won't do it. They do all this today with v4 anyway, so if anything, the 'wrong way' is easier there since they're used to doing it. There has to be some big compelling reason to convince people that global addressing is the right way. We all know the reasons but they're obviously not good enough for enterprise security people. -Laszlo

NAT i s not required for the above. Any firewall can stop incoming packets unless they are part of an established session. NAT doesn't add much of anything, especially given that you can have one-to-one NAT.

-- TTFN, patrick

On Mar 24, 2014, at 9:21 AM, William Herrin <bill@herrin.us> wrote:

On Sun, Mar 23, 2014 at 11:07 PM, Naslund, Steve <SNaslund@medline.com> wrote:

...

I am not sure I agree with the basic premise here. NAT or Private addressing does not equal security.

Hi Steve,

It is your privilege to believe this and to practice it in the networks you operate.

Many of the folks you would have deploy IPv6 do not agree. They take comfort in the mathematical impossibility of addressing an internal host from an outside packet that is not part of an ongoing session. These folks find that address-overloaded NAT provides a valuable additional layer of security.

Which impossibility has been disproven multiple times.

Some folks WANT to segregate their networks from the Internet via a general-protocol transparent proxy. They've had this capability with IPv4 for 20 years. IPv6 poorly addresses their requirement.

Actually, there are multiple implementations of transparent proxies available for IPv6. NAT isn’t the same thing at all. If you want to make your life difficult in IPv6, you can. Nobody prevents you from doing so. It is discouraged and non-sensical, but quite possible at this point. Owen

On Mar 24, 2014, at 8:52 PM, George Herbert <george.herbert@gmail.com> wrote:

On Mon, Mar 24, 2014 at 8:02 PM, Owen DeLong <owen@delong.com> wrote:

On Mar 24, 2014, at 9:21 AM, William Herrin <bill@herrin.us> wrote:

...

On Sun, Mar 23, 2014 at 11:07 PM, Naslund, Steve <SNaslund@medline.com> wrote:

...

I am not sure I agree with the basic premise here. NAT or Private addressing does not equal security.

Hi Steve,

It is your privilege to believe this and to practice it in the networks you operate.

Many of the folks you would have deploy IPv6 do not agree. They take comfort in the mathematical impossibility of addressing an internal host from an outside packet that is not part of an ongoing session. These folks find that address-overloaded NAT provides a valuable additional layer of security.

Which impossibility has been disproven multiple times.

...

Some folks WANT to segregate their networks from the Internet via a general-protocol transparent proxy. They've had this capability with IPv4 for 20 years. IPv6 poorly addresses their requirement.

Actually, there are multiple implementations of transparent proxies available for IPv6. NAT isn’t the same thing at all.

If you want to make your life difficult in IPv6, you can. Nobody prevents you from doing so. It is discouraged and non-sensical, but quite possible at this point.

Owen

Right. fc00::/7 exists. If you want to emulate your internal use of 10.0.0.0/8 plus NAT (or, proxies or load balancers or whatever) in your IPv6 implementation go ahead. Putting in some robust filtering that if the fc00::/7 ever appears outside the internal gateway the traffic goes poof should be as easy as the equivalents for 10, 172.16, 192.168 …

More accurately fd00::/8. fc00::/8 was reserved for ULA coordinated which failed to gain consensus. While IETF did set aside the /7, only fd00::/8 has a legitimate documented purpose. Owen

On Sun, Mar 23, 2014 at 10:07 PM, Naslund, Steve <SNaslund@medline.com>wrote:

As far as printers being a more dangerous attack vector than computers, I definitely don't buy that argument. It does not change in v4 or v6.

Printers are not merely "attack vectors"; they are targets. It only makes sense to describe them solely as potential vectors, if the printer is connected to the LAN the real target is connected to. In which situation: they are equally dangerous. But: there are more hackers that can leverage a computer using generic scripts than can mess with a vulnerable printer, using specialized attacks. Assuming that both stacks are vulnerable to attack I would be less worried

about the printer because I am not aware of any of my printers running malware in v4. I think the PC platform being much more

This is what makes printers more dangerous. Users have no idea what code is running on their printer. It is the perfect place for an attacker to patch the firmware: hole up, and setup their backdoor VPN, proxy, or tunnel, because it's on 24x7 -- rarely replaced, almost never updated --- no antimalware software.

complex and having many more interfaces for active programming like DLLs, Java, ActiveX, etc, are much more the threat. I personally have

The complexity of the available middleware and 3rd party APIs has little to do with what kinds of attacks can be launched from a compromised printer being used to stage attacks; once the device is compromised, the intruder will bring the minimal software they need. You're talking about APIs that greatly expand the attack surface of some computer software. But it does not matter; if the socket protocol used by the printer was not designed with security in mind. One good vulnerability is enough. More known vulnerabilities doesn't make it more dangerous after it is compromised, it just makes it that much more impossible to harden. With the printer --- there is little attention to vulnerabilities, so chances are patches are not even available.

not seen a DDoS attack launched by printers (they may exist but I am

You haven't seen any chargen or snmp activity at all?? DDoS reflection using clumsy appliance defaults is among the most popular attacks to be facilitated by printers.

not aware of them). If I was going to design an attack for a printer, I would think that data theft would be the most dangerous. I have

The most likely use of compromising a printer (following DDoS -- which doesn't require breaking in) is to provide a covert backdoor for staging further compromise attempts or man-in-the-middle attacks. The computer has more data storage, so it is privvy to more confidential information and contents of network traffic from the computer is likely to be the ultimate target. But it just takes one Man-in-the-middle against a LAN computer, with malware covertly injected to a webpage, for a compromised printer to breach a computer.

wondered about multifunction printers emailing print data to someone but I have never seen that yet.

Maybe. Is an intruder going to go through the trouble to compromise a printer -- just to misdirect printouts? Probably not. But this requires profiling the intruder versus information at risk -- They want computing power, banking information, SSNs: usernames/passwords. Typically stuff you will never find on printouts --- particularly within an org whose staff are aware that documents sent to network printers go over the LAN unencrypted, and therefore: your printouts should never contain that kind of information.

Steven Naslund Chicago IL

On Monday, March 24, 2014 02:41:00 AM Timothy Morizot wrote:

The original assertion was that there are unaddressed security weaknesses in IPv6 itself preventing its adoption. At least that's the way I read it. And that assertion is mostly FUD.

The risks have less to do with IPv6, and more to do with the fact that boxes that lived on RFC 1918 behind NAT44 "security gateways" may now, very possibly, be given a GUA address that now exposes them directly to the Interweb. Mark.

On Mar 23, 2014, at 5:24 PM, Mike Hale <eyeronic.design@gmail.com> wrote:

"I wasn't aware that calling out FUD was derisive, but whatever." It's derisive because you completely dismiss a huge security issue that, given the state of IPv6 adoption, a great majority of companies are facing.

I would say that calling it FUD was fair game in this case. Ferg claimed it was a “new unrelated attack”. In reality, it’s pretty much the same attack as most ARP attacks that exist in IPv4 and there are well known mitigations just as in IPv4 with similar difficulties and tradeoffs in their deployment. Sure, having 18 quintillion host addresses on a subnet vs. <254 creates some differences in the scale at which some of these attacks can be carried out, but that’s more a matter of scale than a matter of radically different attack surface.

Calling it FUD is completely wrong because it *is* a legitimate security issue for most businesses. Sure, you've got the few who have been able to properly plan for and secure their networks against the increased attack surface of IPv6, but again...most companies haven’t.

It’s no more legitimate than the similar issues in IPv4. IPv6 doesn’t actually present a significantly increased attack surface, it presents a very similar attack surface. The shape is a little different in some of the details, but the overall size and shape is pretty similar to IPv4.

Slinging false proclamations of FUD is as harmful as FUD itself.

I wouldn’t say that either set of statements was 100% FUD or 100% non-FUD. I will say that vendors making hay out of IPv6 vulnerabilities as if they were novel or different from existing wide-spread IPv4 vulnerabilities in order to increase profits or reduce demands for IPv6 in their products is a fairly common practice that has been far more harmful than any IPv6 attack surface overall. Owen

On Sun, Mar 23, 2014 at 4:49 PM, Timothy Morizot <tmorizot@gmail.com> wrote:

...

On Mar 23, 2014 6:21 PM, "Paul Ferguson" <fergdawgster@mykolab.com> wrote:

...

Says you.

And many others. My comments were actually reiterating what I commonly see presented today.

...

On the other hand, there are beaucoup enterprise networks unwilling to consider to moving to v6 until there are management, control, administrative, and security issues addressed.

Whereas there are other enterprise networks, including mine, who are actively deploying IPv6 and have been for a number of years now. So unless you can come up with something truly novel that we haven't already dealt with, I'll stick by my use of FUD.

...

You can continue to deride our issues, and make derisive comments until your heart's content, but it does not change reality.

I wasn't aware that calling out FUD was derisive, but whatever.

Cheers,

Scott

-- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0

On Mar 22, 2014, at 10:16 AM, Nick Hilliard <nick@foobar.org> wrote:

On 22/03/2014 16:29, Doug Barton wrote:

...

It is a mistake to believe that the only reason to add IPv6 to your network is size. Adding IPv6 to your network _now_ is the right decision because at some point in the not-too-distant future it will be the dominant network technology, and you don't want to get left behind.

not wanting to rain on anyone's parade, but people have been claiming this since the days of IPng. Granted, we're a couple of years after IANA runout and two RIRs are also in post-runout phase, but the level of pain associated with continued deployment of ipv4-only services is still nowhere near the point that ipv6 can be considered a viable alternative.

Nick

True. However, if you wait until that point to start deploying IPv6, you’re in for a LOT of pain during that protracted emergency transition phase you just volunteered for. OTOH, if you implement IPv6 in parallel to your IPv4 from this point forward, there’s very little additional pain and retrofitting your IPv4 can proceed at some pace until complete. After that, you can turn off IPv4 as soon as you don’t need it any more and enjoy the show while everyone else plays catchup. Owen

Additional support on my feeling of DO and IPv6, is DO's stance of directly not even allowing IPv6 tunnels to HE, SiXXs, or any of the other providers by specifically teliing them not to allow connections from your IPv4 address space.

Say *what*? I've got HE tunnels into DO, purely because they won't get their finger out and offer native v6, but the rest of the service currently outweighs the hassle of tunneling. If this is going to get blocked, I'll be reversing the migration of my existing VPS services elsewhere *into* DO, and starting to look for yet-another provider :( I've already had a rather strange conversation with SIXXS where they swore seven ways from Sunday I couldn't have a tunnel because DO already offer native v6, despite sending them numerous official statements to the contrary, but trying to reason with SIXXS is always "interesting"... Regards, Tim.

I agree with "one" thing herein....

In order for IPv6 to truly work, everyone needs to be moving towards IPv6.

Yep, chicken and the egg. I agree. We built an IPv6 "native" network - no tunneling - no customers to speak of ... didn't even bother to start IPv6 peering on it.

Maintaining dual protocols for the entire internet is problematic, wasteful, and horribly inefficient at best. Bottom line, the internet outgrew IPv4 almost 30 years ago and we’ve been using various hacks like NAT as a sort of IPv4 life-support ever since.

30 years - oh, come on now - maybe it outgrown on someone's EBITDA chart they handed an investor. At least a couple of decades of exaggeration in that number.

Ask any doctor about the prospects for a patient on life support for years at a time and they will probably laugh at you. Patients rarely survive more than a few days on life support, let alone weeks, months, or even years.

Yes, we’ve done really well with internet life support. So well that many have been lulled into a false sense of safety believing that these extreme measures can be continued indefinitely and scaled well beyond their breaking points.

There is little visibility into the escalating cost and complexity of these measures and even less awareness of the relative ease of deploying IPv6 compared to most of these mechanisms.

Sorry Owen - bad analogy - unlike a person, IPv4 won't die because it can't accommodate more - here's a reality analogy for you. In the Internet Casino, all the Internet black jack tables are full. All seats taken. The players don't want to play with the new blue chip IPv6 currency. So the house simply raises IPv4 green chip minimum limit for a seat. An there you have it, how much is someone willing to pay for space in the Internet casino. Well, it's much more than free and probably close to the dollar level in the presentation by Lee Howard at an ARIN meeting (I think it was in Barbados or maybe I have that meeting place wrong and it was NANOG) ... Well, $40/month per IP address will be the pain level for all customers to finally cash-in the IPv4 chips and move to IPv6. While the world is not capitalistic, the USA is. Just because it works in Sweden doesn't mean it's ready to work here (Health Care). So what percentage of web pages are my USA customers reading in foreign languages ? Gee, the world doesn't need more IPv4 space to make an english page available to reach a US customer. Not much when they move their language base of users to IPv6 they will find they have plenty of IPv4 space left over. And what percentage of my customer base needs to put up IPv6 web pages ? Not many most of the world can't afford our goods - so that leaves a small percentage of US sites that need IPv6 and probably already have begun that in place. Thus far, IPv6 has been the "Field of Dreams" .... those of us who have built it, we know they have not yet come (the IPv6 customers). That's all this discussion is really about is "when will they come". I know the core of the Internet will be IPv4 for many years. All one has to do is talk to a few customer to find out that they are in no hurry. It's a no-brainer, because , none of us charges a customer more than than lunch money for an IPv4 address. Now, if you tell me all the porn site owners were great net citizens, ready to move to IPv6 and shut off IPv4 access, well then I can see things moving along much faster. Bob Evans Founder/CTO Fiber Internet Center

Owen

On Mar 22, 2014, at 2:25 AM, Bryan Socha <bryan@digitalocean.com> wrote:

...

Fair point. There are some situations that do need more than most, but aren't they the ones that should be on ipv6 already???????

I know a few are shouldn't I be on ipv6 and that's fair too. I'm plqnnning some speaking engagements to cover that. Its not blind and ignoring. On Mar 22, 2014 4:36 AM, "TJ" <trejrco@gmail.com> wrote:

...

Millions of IPs don't matter in the face of X billions of people, and XX-XXX billions of devices - and this is just the near term estimate. (And don't forget utilization efficiency - Millions of IPs is not millions of customers served.)

Do IPv6. /TJ

On Mar 22, 2014 3:09 AM, "Bryan Socha" <bryan@digitalocean.com> wrote:

...

As someone growing in the end of ipv4, its all fake. Sure, the rirs

will

...

run out, but that's boring. Don't believe the fake auction sites. Fair price of IP at the end is $1 for bad Rep $2 for barely used, $3 for no spam and $4 for legacy. Stop the inflation. Millions of IPS exist, there is no shortage and don't lie for rirs with IPS left.

On 3/24/14 9:12 PM, "Bob Evans" <bob@FiberInternetCenter.com> wrote:

I agree with "one" thing herein....

...

In order for IPv6 to truly work, everyone needs to be moving towards IPv6.

Yep, chicken and the egg. I agree. We built an IPv6 "native" network - no tunneling - no customers to speak of ... didn't even bother to start IPv6 peering on it.

How would there be traffic if you have no peering?

An there you have it, how much is someone willing to pay for space in the Internet casino. Well, it's much more than free and probably close to the dollar level in the presentation by Lee Howard at an ARIN meeting (I think it was in Barbados or maybe I have that meeting place wrong and it was NANOG) ... Well, $40/month per IP address will be the pain level for all customers to finally cash-in the IPv4 chips and move to IPv6.

I wish it was Barbados! NANOG56. http://www.nanog.org/meetings/nanog56/presentations/Wednesday/wed.general.h oward.24.wmv

Thus far, IPv6 has been the "Field of Dreams" .... those of us who have built it, we know they have not yet come (the IPv6 customers). That's all this discussion is really about is "when will they come".

Some of us have quite a few IPv6 customers: http://www.worldipv6launch.org/measurements/ And we see significant traffic from those users. :-)

I know the core of the Internet will be IPv4 for many years. All one has to do is talk to a few customer to find out that they are in no hurry. It's a no-brainer, because , none of us charges a customer more than than lunch money for an IPv4 address.

Depends on what you mean by "core." For some values of "core," the Internet is already dual-stack.

Now, if you tell me all the porn site owners were great net citizens, ready to move to IPv6 and shut off IPv4 access, well then I can see things moving along much faster.

Feel free to offer them a discount for dual-stack, and a deeper discount for IPv6-only. Unfortunately, I don't know any porn site operators, so I haven't been able to have conversations with them about the economics of IPv6. Lee

...

...

Thus far, IPv6 has been the "Field of Dreams" .... those of us who have built it, we know they have not yet come (the IPv6 customers). That's all this discussion is really about is "when will they come".

Some of us have quite a few IPv6 customers: http://www.worldipv6launch.org/measurements/ And we see significant traffic from those users. :-)

Maybe my isolation in silicon valley causes me to have a different IPv6 experience. Not much IPv6 happening here. I heard Google my have topped over 2% traffic that is IPv6. Significant ? Not from where I am sitting.

There’s actually lots of IPv6 happening in Silicon Valley. I’ve been running IPv6 for years and so has my employer. Your Google data is old… They’re well over 4% and it’s been doubling about every 3-6 months, so I’d expect to see upwards of 16% by the end of the year, but remember, that’s traffic that chose IPv6 based on happy eyeballs and doesn’t represent all traffic that could have gone IPv6 or even all traffic that would have gone best over IPv6. If Micr0$0ft would publish the stats of native vs. teredo from the xbox one, I bet we’d have a better idea of what percentage of folks are running IPv6 for real. I think it’s a lot more than you seem to believe. Of the major consumer providers in the area, AT&T and SPRINT Wireless are the only ones I’m aware of that are completely unable to do IPv6. Even some of the smaller residential providers are now doing some IPv6 and I hear rumors that some AT&T DSL and uVerse customers can now get IPv6.

We give away the IPv6 to every business on a second port - to make their life easy and encourage them to play with it. Unfortunately, few try it at all.

We make IPv6 available to all of our customers on the same port which seems to make their life even easier and many of our customers are using it. Perhaps this is food for thought. Owen

On Sat, Mar 22, 2014 at 11:30 AM, Bryan Socha <bryan@digitalocean.com> wrote:

Oh btw, how many ipv4s are you hording with zero justification to keep them? I was unpopular during apricot for not liking the idea of no liability leasing of v4. I don't like this artificial v4 situation every eyeball network created. Why is v4 a commodity and asset? Where is the audits. I can justify my 6 /14s, can you still?

Oh I so agree with this one. But alas yes, IPv4's days are counted and I doubt there's any turning back. As a NA myself, I see day on day where smaller ISPs are forced to dish out large network blocks (/16s) to be able to have access to large unefficiently planned broadband networks in order to service PPPoE terminations (at least, here in ZA). These ISPs are forced to 'hand out' /16 networks for the large telco's to distribute to their respective BRAS devices.... Meanwhile, the ISP does not even have 20K customers - nevermind the fact that more than likely 50% of that customer base is not even 'always' connected... It's due to waisting like this, that the shortage is there and that other players with legitimate requirements (such as going provider independant) cannot obtain address space. And it is continueing to this very day. I'm definately all for proper audits, stricter audits, and more importantly the releasing of unused address space back to the respective registries. -- Regards, Chris Knipe

On Sat, Mar 22, 2014 at 10:33 AM, Justin M. Streiner <streiner@cluebyfour.org> wrote:

All of these 'Hail Mary' options for 'saving' IPv4 really are pointless.

Hi Justin, IPv4 is like the U.S. Penny. It'll be useless long before it goes away. And right now it's far from useless. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004

On Saturday, March 22, 2014 05:54:06 PM Justin M. Streiner wrote:

Interesting analogy, but it misses the larger point. The larger point is that the ongoing effort to squeeze more mileage out of IPv4 will soon [1] outweigh the mileage we (collectively) get out of it. IMHO, that effort is better invested in preparing for and deplying IPv6. Things like LSN/CGN are stop-gaps that result in performance problems for people behind them, and aren't terribly useful for people who need to run inbound services. Shaking down entities (to the extent that they can be shaken down) that have chunks of IPv4 they're not currently using doesn't change the end-game for IPv4.

And to keep into perspective, the fact that a good portion of the registry community have run out of IPv4 space to allocate. A number of existing and new ISP's are going to find that getting IPv6 going is probably a better solution than keeping IPv4 alive (many will learn this the hard way). Heck, it won't surprise me if some popular OTT and social networking providers "force" the IPv6 issue since democracy isn't often the best way to get something like this done. In such a case, where you are still pushing the case for IPv4, how do you envisage things will look on your side when everybody else you want to talk to is either on IPv6, or frantically getting it turned up? Do you reckon anyone will have time to help you troubleshoot patchy (for example) IPv4 connectivity when all the focus is on IPv6? AFRINIC still have lots of IPv4 space. I'm not sure that gives operators in that region any advantage over anyone else, if the rest of the world is active on IPv6, i.e., while it may be easier to justify a /8 of IPv4 and get it from a registry that still has space, you're likely doing yourself a disservice in taking this route (and spending all the time and energy numbering out of that /8), because that /8 won't be very helpful if the most of the rest of the Internet is letting IPv4 go. Mark.

On Saturday, March 22, 2014 09:57:04 PM John Levine wrote:

We've just barely started to move from the era of free IPv4 to the one where you have to buy it, and from everyhing I see, there is vast amounts of space that will be available once people realize they can get real money for it. The prices cited a couple of messages back seem to be in the ballpark. It will be a long time before the price of v4 rises high enough to make it worth the risk of going v6 only.

New ISP's are born everyday. Some of them will be able to have a "Buy an ISP that has IPv4" or "Buy IPv4 space from known brokers" line item in their budget as part of their launch plans. Most won't. Mark.

On Sunday, March 23, 2014 07:10:37 AM John Levine wrote:

In Africa, I suppose, but here in North America, the few remaining ISPs that aren't part of giant cable or phone companies are hanging on by their teeth.

Incidentally, this doesn't apply to Africa today, because AFRINIC still have lots of IPv4 space to feed any new entrant to their heart's content. I have mates in Asia-Pac, North America and Europe that will be the ones sweating if they are a new start-up. A friend recently started a mobile operation in Malaysia two years ago. You can imagine the problem they are having rolling out and scaling their 3G/3G data service. And if AFRINIC do run out of their IPv4 space, I can almost guarantee you that any new start-ups in Africa will NOT be able to have "IPv4 acquisition" line items in their budget.

Also, although it is fashionable to say how awful CGN is, the users don't seem to mind it at all.

Users won't complain until the CGN starts to do bad things to their traffic, like run out of Layer 4 ports per IP address due to increasing connectedness of applications, add delay to applications getting network, CGN failure, traffic tromboning e.t.c. Operators of CGN's will cry at some point. It's different for different operators, as some are happy throwing millions of CGN $$ at the problem. Mark.

In message <20140323051037.94159.qmail@joyce.lan>, "John Levine" writes:

...

...

It will be a long time before the price of v4 rises high enough to make it worth the risk of going v6 only.

New ISP's are born everyday.

Some of them will be able to have a "Buy an ISP that has IPv4" or "Buy IPv4 space from known brokers" line item in their budget as part of their launch plans.

Most won't.

In Africa, I suppose, but here in North America, the few remaining ISPs that aren't part of giant cable or phone companies are hanging on by their teeth.

Also, although it is fashionable to say how awful CGN is, the users don't seem to mind it at all.

Basically because none of them have ever been on the Internet proper where they can connect to their home machines from wherever they are in the world directly. If you don't know what it should be like you don't complain when you are not getting it. ISP's have done a good job of brain washing their customers into thinking that they shouldn't be able to run services from home. That all their machines shouldn't have a globally unique address that is theoritically reachable from everywhere. That NAT is normal and desiriable. I was at work last week and because I have IPv6 at both ends I could just log into the machines at home as easily as if I was there. When I'm stuck using a IPv4 only service on the road I have to jump through lots of hoops to reach the internal machines. Mark

R's, John

-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

On Mar 23, 2014 1:11 PM, "Mark Tinka" <mark.tinka@seacom.mu> wrote:

On Sunday, March 23, 2014 06:57:26 PM Mark Andrews wrote:

...

I was at work last week and because I have IPv6 at both ends I could just log into the machines at home as easily as if I was there. When I'm stuck using a IPv4 only service on the road I have to jump through lots of hoops to reach the internal machines.

I expect this to change little in the enterprise space. I think use of ULA and NAT66 will be one of the things enterprises will push for, because how can a printer have a public IPv6 address that is reachable directly from the Internet, despite the fact that there is a properly configured firewall at the perimetre offering half-decent protection?

That is what a firewall is for. Drop new inbound connections, allow related, and allow outbound. Then you allow specific IP/ports to have inbound traffic. You may also only allow outbound traffic for specific ports, or from your proxy.

On Sun, Mar 23, 2014 at 11:27 AM, Philip Dorr <tagno25@gmail.com> wrote:

On Mar 23, 2014 1:11 PM, "Mark Tinka" <mark.tinka@seacom.mu> wrote:

...

On Sunday, March 23, 2014 06:57:26 PM Mark Andrews wrote:

...

I was at work last week and because I have IPv6 at both ends I could just log into the machines at home as easily as if I was there. When I'm stuck using a IPv4 only service on the road I have to jump through lots of hoops to reach the internal machines.

I expect this to change little in the enterprise space. I think use of ULA and NAT66 will be one of the things enterprises will push for, because how can a printer have a public IPv6 address that is reachable directly from the Internet, despite the fact that there is a properly configured firewall at the perimetre offering half-decent protection?

That is what a firewall is for. Drop new inbound connections, allow related, and allow outbound. Then you allow specific IP/ports to have inbound traffic. You may also only allow outbound traffic for specific ports, or from your proxy.

i would say the more appropriate place for this policy is the printer, not a firewall. For example, maybe a printer should only be ULA or LLA by default. i would hate for people to think that a middle box is required, when the best place to provide security is in the host. Other layers are needed as required, but it is sad that we don't look to the host it self as a first step. CB

On Sun, Mar 23, 2014 at 12:13 PM, Mark Tinka <mark.tinka@seacom.mu> wrote:

On Sunday, March 23, 2014 09:05:54 PM Cb B wrote:

...

i would say the more appropriate place for this policy is the printer, not a firewall. For example, maybe a printer should only be ULA or LLA by default.

i would hate for people to think that a middle box is required, when the best place to provide security is in the host. Other layers are needed as required, but it is sad that we don't look to the host it self as a first step.

I would support adding security at the host-level, especially because with a centralized firewall, internal infrastructure is usually left wide open to internal staff, with trust being the rope we all hang on to to keep things running.

However, if pratical running of the Internet has taught us anything, host-based firewalling (especially in purpose- specific devices like printers, Tv sets, IP phones, IP cameras, e.t.c.) is a long way away from what you can get with a centralized firewall appliance.

Do I like it? No. I run a simple packet filter (IPfw) on my MacBook - it does what I need. But we know Joe and Jane won't want things they can't click; and even though they had things they could click, they don't want to have to understand all these geeky things about their computers.

Mark.

Mark, i think we are largely on the same page. I believe that "home firewalls" in the residential broadband space are likely the most insecure part of the entire internet. They are very rarely updated with software and frequently ship with terrible terrible bugs, much worse than what we have seen in Windows for the last 10 years. For example, http://tools.cisco.com/security/center/mcontent/CiscoSecurityAdvisory/cisco-... Why try to hack all the devices in your home when the hackers can simply crack your CPE / firewall / router and own all your traffic, reset your DNS server to a malware box, ..... I am sure this community knows there are many many more problems just like this one in CPE. I don't see a lot of accountability or change in this space, yet people believe these firewalls help. My hope is that folks stop equating firewalls with security, when the first step is to secure the host, accountability is with the host, then layer other tools as needed. CB

Hi all, Le 23/03/2014 20:13, Mark Tinka a écrit :

On Sunday, March 23, 2014 09:05:54 PM Cb B wrote:

...

i would say the more appropriate place for this policy is the printer, not a firewall. For example, maybe a printer should only be ULA or LLA by default.

I would support adding security at the host-level, especially because with a centralized firewall, internal infrastructure is usually left wide open to internal staff, with trust being the rope we all hang on to to keep things running.

When speaking of IPv6 deployment, I routinely hear about host security. I feel like it should be stated that this is *in no way* an IPv6 issue. May the device be ULA, LLA, GUA or RFC1918-addressed, the device is at risk anyway. If this is the only argument for delaying IPv6 deployment, this sounds more like FUD to me ;-) Denis

On Mon, 2014-03-24 at 08:38 +0200, Mark Tinka wrote:

In an ideal IPv6 world, all hosts have GUA's, and in this case, host security becomes a bigger problem, because now the host is directly accessible without a NAT66 in between (we hope).

The mantras from my training courses: Addressable is not the same as accessible; routable is not the same as routed. Just because you give every host a globally routable address doesn't mean you have to route them. Just because you route them doesn't mean you have to forward all traffic to or from them. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) http://www.biplane.com.au/kauer http://twitter.com/kauer389 GPG fingerprint: EC67 61E2 C2F6 EB55 884B E129 072B 0AF0 72AA 9882 Old fingerprint: B862 FB15 FE96 4961 BC62 1A40 6239 1208 9865 5F9A

On Mon, Mar 24, 2014 at 3:00 AM, Karl Auer <kauer@biplane.com.au> wrote:

Addressable is not the same as accessible; routable is not the same as routed.

Indeed. However, all successful security is about _defense in depth_. If it is inaccessible, unrouted, unroutable and unaddressable then you have four layers of security. If it is merely inaccessible and unrouted you have two. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004

On Mon, Mar 24, 2014 at 8:31 AM, Joe Greco <jgreco@ns.sol.net> wrote:

...

all successful security is about _defense in depth_. If it is inaccessible, unrouted, unroutable and unaddressable then you have four layers of security. If it is merely inaccessible and unrouted you have two.

Time to give up two layers of meaningless security for the riches offered by the vastness of the new address space.

Hi Joe, You'd expect folks to give up two layers of security at exactly the same time as they're absorbing a new network protocol with which they're yet unskilled? Does that make sense to you from a risk-management standpoint? -Bill -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004

On Mon, 24 Mar 2014 13:13:43 -0400, William Herrin said:

You'd expect folks to give up two layers of security at exactly the same time as they're absorbing a new network protocol with which they're yet unskilled? Does that make sense to you from a risk-management standpoint?

The problem is that the two layers of "security" that they're "giving up" are made from the same fabric as the Emperor's new clothes....

On Mon, Mar 24, 2014 at 1:37 PM, <Valdis.Kletnieks@vt.edu> wrote:

On Mon, 24 Mar 2014 13:13:43 -0400, William Herrin said:

...

You'd expect folks to give up two layers of security at exactly the same time as they're absorbing a new network protocol with which they're yet unskilled? Does that make sense to you from a risk-management standpoint?

The problem is that the two layers of "security" that they're "giving up" are made from the same fabric as the Emperor's new clothes....

Howdy, In an environment of increasing breaches despite massive attention and expenditure on cyber security, you'll find that giving up any layer of security is a very hard sell. You'll find convincing folks to deploy new technologies which demand that they give up a layer of security an even harder sell. And of course everybody likes to be told that they're an idiot by someone whose explanation of the error in their reasoning consists of restating the claim of error in the form of a metaphor. But don't let me dissuade you from trying. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004

On 03/24/2014 09:20 AM, William Herrin wrote:

On Mon, Mar 24, 2014 at 3:00 AM, Karl Auer <kauer@biplane.com.au> wrote:

...

Addressable is not the same as accessible; routable is not the same as routed. Indeed. However, all successful security is about _defense in depth_. If it is inaccessible, unrouted, unroutable and unaddressable then you have four layers of security. If it is merely inaccessible and unrouted you have two.

A distinction without a difference, IMHO. Either I can send you an incoming SYN or I can't. The real battle here, IMHO, is to get the next gen CPE vendors to do the right thing. NANOG folks ought to be keeping tabs on the Homenet working group and then DEMAND that any CPE support its security, etc, baselines. Mike

Hi Mike,

You can either press the big red button and fire the nukes or you can't, so what difference how many layers of security are involved with the "Football?"

I say this with the utmost respect, but you must understand the principle of defense in depth in order to make competent security decisions for your organization. Smart people disagree on the details but the principle is not only iron clad, it applies to all forms of security, not just IP network security.

The problem here is that what's actually going on is that you're now enshrining as a "security" device a hacky, ill-conceived workaround for a lack of flexibility/space/etc in IPv4. NAT was not designed to act as a security feature. If you want more layers of security, put a second firewall into your design. Don't perpetuate horrid IPv4 hacks that were necessary for specific reasons into IPv6 where those hacks are no longer needed. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.

On 3/24/14 1:37 PM, "William Herrin" <bill@herrin.us> wrote:

On Mon, Mar 24, 2014 at 9:25 AM, Joe Greco <jgreco@ns.sol.net> wrote:

...

...

I say this with the utmost respect, but you must understand the principle of defense in depth in order to make competent security decisions for your organization. Smart people disagree on the details but the principle is not only iron clad, it applies to all forms of security, not just IP network security.

The problem here is that what's actually going on is that you're now enshrining as a "security" device a hacky, ill-conceived workaround for a lack of flexibility/space/etc in IPv4. NAT was not designed to act as a security feature.

Hi Joe,

That would be one of those "details" on which smart people disagree. In this case, I think you're wrong. Modern NAT superseded the transparent proxies and bastion hosts of the '90s because it does the same security job a little more smoothly. And proxies WERE designed to act as a security feature.

What kinds of devices are we talking about here? Are we talking about the default NAT on a home network router, or an enterprise-level NAT operating on a firewall? The NAT on home gateways may be a full-cone NAT. This allows easier setup of online gaming, for instance, or other applications where an inbound SYN is required. This provides no security, since as soon as a connection is established, all traffic is allowed. Even restricted cone NATs provide little protection, just a bit of guessing that even a human could manage. If we're talking about an enterprise firewall, then I don't understand--we're talking about a firewall. If it implements a symmetric NAT in addition to a stateful firewall, then it's implementing the same function twice. But, hey, it's your network, if security-through-obscurity is one of your defense in depth layers, that's fine. You may use NPT66 with ULA; that function is defined. Lee

On 3/24/14 2:38 PM, "William Herrin" <bill@herrin.us> wrote:

On Mon, Mar 24, 2014 at 2:23 PM, Lee Howard <Lee@asgard.org> wrote:

...

On 3/24/14 1:37 PM, "William Herrin" <bill@herrin.us> wrote:

...

That would be one of those "details" on which smart people disagree. In this case, I think you're wrong. Modern NAT superseded the transparent proxies and bastion hosts of the '90s because it does the same security job a little more smoothly. And proxies WERE designed to act as a security feature.

What kinds of devices are we talking about here? Are we talking about the default NAT on a home network router, or an enterprise-level NAT operating on a firewall?

Hi Lee,

I don't see NAT as a deployment issue for residential networks. Most folks just hook their computer up to whatever CPE the vendor sends them without any further attention.

...

If we're talking about an enterprise firewall, then I don't understand--we're talking about a firewall. If it implements a symmetric NAT in addition to a stateful firewall, then it's implementing the same function twice. But, hey, it's your network, if security-through-obscurity is one of your defense in depth layers, that's fine.

"Obscurity" offers one or more defense layers. If you disagree, post your passwords here.

One that is largely mocked by security professionals. However, ULA can do this.

Unaddressibility is a second defense layer.

I offered ULA+NPT66. I don't recommend it, but it has been described as working, and provides addresses which are not globally reachable.

Stateful firewalling is a third.

We agree. Lee

On Mon, Mar 24, 2014 at 8:25 AM, Joe Greco <jgreco@ns.sol.net> wrote:

Bill Herrin wrote:

I say this with the utmost respect, but you must understand the

...

principle of defense in depth in order to make competent security decisions for your organization. Smart people disagree on the details but the principle is not only iron clad, it applies to all forms of security, not just IP network security.

The problem here is that what's actually going on is that you're now enshrining as a "security" device a hacky, ill-conceived workaround for a lack of flexibility/space/etc in IPv4. NAT was not designed to act as a security feature.

If you want more layers of security, put a second firewall into your design. Don't perpetuate horrid IPv4 hacks that were necessary for specific reasons into IPv6 where those hacks are no longer needed.

With 24 million small businesses in the US alone, that's way too many

apples.

Precisely. Repeat after me. NAT is not a security feature. Period. It offers no meaningful protection. We've known how to bypass NATs almost from the moment they were developed. Defense in depth has nothing to do with NAT. In our enterprise deployment, it involves two layers of heterogeneous firewalls (protecting multiple security zones from the internal network and the Internet), IPS/IDS, web filters, mail filters, and an active CSIRC monitoring, analyzing, and responding to threats and attacks. If you're an enterprise and don't have something similar in place, then you have no security defense in depth. Thanks goodness our Cybersecurity organization actually comprehends real computer and network security instead of promoting snake oil. Scott

On 3/24/14 10:08 AM, William Herrin wrote:

On Mon, Mar 24, 2014 at 12:28 PM, Michael Thomas <mike@mtcc.com> wrote:

...

On 03/24/2014 09:20 AM, William Herrin wrote:

...

On Mon, Mar 24, 2014 at 3:00 AM, Karl Auer <kauer@biplane.com.au> wrote:

...

Addressable is not the same as accessible; routable is not the same as routed. Indeed. However, all successful security is about _defense in depth_. If it is inaccessible, unrouted, unroutable and unaddressable then you have four layers of security. If it is merely inaccessible and unrouted you have two. A distinction without a difference, IMHO. Either I can send you an incoming SYN or I can't. Hi Mike,

You can either press the big red button and fire the nukes or you can't, so what difference how many layers of security are involved with the "Football?"

I say this with the utmost respect, but you must understand the principle of defense in depth in order to make competent security decisions for your organization. Smart people disagree on the details but the principle is not only iron clad, it applies to all forms of security, not just IP network security.

The point here is that your "depth" is the same with or without nat. The act of address translation does not alter its routability, it's the firewall rules that say "no incoming SYN's without an existing connection state", etc. That, and always has been, the business end of firewalls. The other thing about v6 is that counting on addressibility in any way shape or form is a fool's errand: hosts want desperately to number their interfaces with whatever GUA's they can given RA's, etc. So you may think you're only giving out ULA's, but I wouldn't count on that from a security perspective. v6 is not like DHCPv4 even a little in that respect: if the hosts can get a GUA, they will configure it and use it. Mike

On Mar 24, 2014, at 9:20 AM, William Herrin <bill@herrin.us> wrote:

On Mon, Mar 24, 2014 at 3:00 AM, Karl Auer <kauer@biplane.com.au> wrote:

...

Addressable is not the same as accessible; routable is not the same as routed.

Indeed. However, all successful security is about _defense in depth_. If it is inaccessible, unrouted, unroutable and unaddressable then you have four layers of security. If it is merely inaccessible and unrouted you have two.

That is, frankly, so gross an oversimplification as to be not only misleading, but outright inaccurate in many cases. When considering defense in depth, layer thickness counts as much or more than number of layers. unroutable and unaddressable (which NAT and RFC-1918 arguably don’t actually provide in reality) are roughly equivalent to a slide-lock on a screen door in front of a stateful inspection bank vault door in front of an unrouted iron-bar day-door inside the vault. I would argue that the value added by the screen door and its associated slide lock is near zero in the total equation. Further, since the reality is that NAT and RFC-1918 can be exploited by the attackers to help hide their identity and obscure their activities, they are actually not added depth, but in fact erode the actual security. Further, since it is such a widely held misperception that they provide security, there’s probably a certain amount of negative impact due to the complacency and lack of vigilance that creates as well. Owen

On Monday, March 24, 2014 02:56:13 PM Timothy Morizot wrote:

NAT traversal is and has long been fairly trivial. NAT and RFC1918 provides no meaningful host protection whatsoever and never has. The only thing that limits direct access to internal networks is a stateful firewall. (Well, IPS can also drop packets.) That's true for IPv4 and for IPv6. So an enterprise relying n NAT44 and RFC1918 for internal host protection instead of a stateful firewall already has no meaningful security in place.

Don't disagree with you there. I'm saying many an enterprise (small and large) as well as homes operate this way. There is a lot of unlearning to do. The whole issue is that a number of enterprises "may" only feel safe if IPv6 comes with NAT66, probably on top (or not on top) of a stateful IPv6 firewall. We need to think about how to re-train the enterprise, if we don't want to repeat the erasure of the end-to-end model, second time around. Mark.

On 2014-03-24, "Naslund, Steve" <SNaslund@medline.com> wrote:

If they have a stateful IPv6 firewall (which they should and which most firewall vendors support), they already have what they need to prevent their internal systems from being accessible from the outside. If you are an enterprise and you don't have a stateful firewall, you are in trouble from a security standpoint whether you run v4 or v6. If you cannot configure a stateful firewall to block connections being initiated from outside, you are not qualified to be working with the firewall, v4 or v6 does not matter. If someone is relying on NAT in case their firewall is misconfigured, they have major issues with security.

In the home, I am not sure what the major issue is there either. How many CPE devices have you seen that do not implement basic firewall functionality? People may not use them correctly but that is no more an issue with v6 than it is with v4. Most CPE even comes out of the box blocking inbound connections by default.

Tell that to our little D-Link AP/router with stateless filters only for v6, and broken config options that make it impossible to apply even that to a tunnel interface (HE). I agree with you on pushing v6 adoption and that the at the root of it you should have a stateful firewall be it v4 or v6, but: - if this thread is any indication and as per your first paragraph, way too many orgs are depending on NAT as a security feature and v6 is exposing that weakness in their posture - home CPE implementations are largely crap, and good luck getting a decent portion of them supporting (functional) stateful v6 firewalls

Steve

-- Hugo

-----Original Message----- From: Mark Tinka [mailto:mark.tinka@seacom.mu] Sent: Monday, March 24, 2014 11:35 AM To: Timothy Morizot Cc: NANOG list Subject: Re: misunderstanding scale

...

...

Don't disagree with you there.

...

...

I'm saying many an enterprise (small and large) as well as homes operate this way. There is a lot of unlearning to do.

...

...

The whole issue is that a number of enterprises "may" only feel safe if IPv6 comes with NAT66, probably on top (or not on top) of a stateful IPv6 firewall.

...

...

We need to think about how to re-train the enterprise, if we don't want to repeat the erasure of the end-to-end model, second time around.

...

...

Mark.

-- Hugo Slabbert Network Specialist Phone: 604.606.4448 Email: hslabbert@stargate.ca Stargate Connections Inc. http://www.stargate.ca

Exactly right. In fact that is generous because the v6 host having a stateful firewall has a real protocol aware firewall (and often bundled IDS/IPS capability) not just a NAT to protect him. The NAT provides almost no security once a single host behind the NAT is compromised and makes an outbound connection. Bang, instant VPN connection to the internal network. A perimeter defense relying on NAT is a house of cards that only needs one nick for the whole thing to come down. Lots and lots of enterprises count on a hard perimeter and almost nothing behind it so once I am in behind your NAT, you are unlikely to notice it until something real bad happens. That is the state of most enterprise network security today. C'mon guys how many Botnets and DDoS attacks do we need to see coming from home computers that are almost all behind NATs to realize that NAT is not a security feature. For you service providers out there, how many of your residential customers behind your NAT do you think are compromised in some way. If you can find a large enterprise that has not one piece of malware running on a single workstation, I will be surprised. With so many BYODs and laptops going in and out of your NAT perimeter there is no way you can assert that nothing behind your NAT is compromised. At least with v6 we can have a better idea of where a rogue connection is coming from. Look at it this way. If I see an attack coming from behind your NAT, I'm gonna deny all traffic coming from your NAT block until you assure me you have it fixed because I have no way of knowing which host it is coming from. Now your whole network is unreachable. If you have a compromised GUA host I can block only him. Better for both of us, no? How about a single host spamming behind your NAT blocking your entire corporate public network from email services? Anyone ever see that one. Ipv6 GUAs allow us to use fly swatters instead of sledgehammers to deal with that. Maybe GUAs will convince (scare) more enterprise users to actually treat the internal network as an environment that needs to be secured as well. We can only hope. Steven Naslund

...

Bzzzt... But thanks for playing.

...

An IPv6 host with a GUA behind a stateful firewall with default deny is every bit as secure as an iPv4 host with an RFC-1918 address behind a NAT44 gateway.

...

Owen

-----Original Message----- From: Naslund, Steve [mailto:SNaslund@medline.com] Sent: Monday, March 24, 2014 10:48 PM To: Owen DeLong; mark.tinka@seacom.mu Cc: nanog@nanog.org Subject: RE: misunderstanding scale

Look at it this way. If I see an attack coming from behind your NAT, I'm gonna deny all traffic coming from your NAT block until you assure me you have it fixed because I have no way of knowing which host it is coming from. Now your whole network is unreachable. If you have a compromised GUA host I can block only him. Better for both of us, no?

That is assuming that the infected piece does not request another address in the /64, and that the person blocking at the target end blocks a /128 instead of the /64.

How about a single host spamming behind your NAT blocking your entire corporate public network from email services? Anyone ever see that one. Ipv6 GUAs allow us to use fly swatters instead of sledgehammers to deal with that.

I don't want to try to even think about SMTP on IPv6. Reputation of email servers as well as the whole thought process of spam control rely on a list of IP address. IPv6 adds an entirely new aspect to it.

Maybe GUAs will convince (scare) more enterprise users to actually treat the internal network as an environment that needs to be secured as well. We can only hope.

Most enterprise admins, segment their BYOD (wifi) network from the production network. Some will even use a different WAN ip for the wifi network or in the minimum block outbound request to well known services ports. I generally see where the only outbound connections allowed are http and https. All other ports are blocked.

Steven Naslund

...

...

Bzzzt... But thanks for playing.

...

...

An IPv6 host with a GUA behind a stateful firewall with default deny is every bit as secure as an iPv4 host with an RFC-1918 address behind a NAT44 gateway.

I can't argue there.....

...

...

Owen

If you want to do address-based reputations for v6 similar to v4, my guess is that it will start to aggregate to at least the /64 boundary ...

It says a lot about the state of the art that people are still making uninformed guesses like this, non ironically. On the one hand /64 is too coarse, because there are hosting providers that put multiple customers in a single /64. If you filter at that granularity, you'll get a lot of false positives and collateral damage. (When asked why they did something that dumb, they've tended to blame equipment vendors.) On the other hand, /64 is much too fine. Roadrunner assigns my cable connection a /50*, so even if you're aggregating at /64, there are now 16K different incarnations of me to block, instead of the one in IPv4. Businesses typically get a /48 so they have 64K incarnations. It would be nice if there were an efficient and reliable way to ask networks what their customer suballocation size is, but there isn't, so you have to hope rwhois will work and be fast enough, or guess, often guessing wrong. There also isn't any agreed way to publish DNSBLs with variable size ranges other than rsync'ing the whole file. IANA has handed out /12s to the RIRs, so each of those is 2^52 /64s, a number that's way out in the absurd-o-sphere. Large mail providers all agree that v6 senders need to follow good mail discipline, but are far from agreeing what that means. It certainly means proper rDNS, but does it mean SPF? DKIM on all the mail? TLS on the connections? At this point, I don't know and neither does anyone else. Fortunately we have at least another decade of full IPv4 mail connectivity to figure it out. For anyone who points out that v6 mail works now, you're right, it does, but that's only because botnets don't use it yet other than occasionally by accident on dual stacked hosts so the amount of spam is much lower than on ipv4 and there isn't much address hopping. With any luck they never will, since bot mail still works OK for them on v4, but if they do, and they start doing address hopping, it'll be really ugly. R's, John * - yes, it's a /50, their rwhois says so. And I know because whenever my modem reboots, it assigns me a /64 more or less at random from that /50 even though they tell me it's supposed to keep giving me the same one. See prior comments about mostly working.

On Tue, Mar 25, 2014 at 1:43 PM, Brielle Bruns <bruns@2mbit.com> wrote:

On 3/25/14, 11:23 AM, John Levine wrote:

...

Large mail providers all agree that v6 senders need to follow good mail discipline, but are far from agreeing what that means. It certainly means proper rDNS, but does it mean SPF? DKIM on all the mail? TLS on the connections? At this point, I don't know and neither does anyone else. Fortunately we have at least another decade of full IPv4 mail connectivity to figure it out.

So, what's everyone's feelings about a rather large provider who blocks IPv6 e-mail that has no RDNS, even though the sending domain has SPF records allowing the block, and proper DKIM set up?

*looks directly at Google*

Nothing like poorly thought out policy to break a rather successful IPv6 roll-out for multiple customers.

Just an anecdotal observation.... what G appears to be doing is flagging emails, received over IPv6, that are below a certain size threshold. I have zero problems sending bulk emails (discussions lists), over IPv6, to G end users, but I do see consistent problems sending small mgmt alerts (i.e. monit/munin) over IPv6 to G. -Jim P.

On 3/25/14, 11:56 AM, John Levine wrote:

I think this would be a good time to fix your mail server setup. You're never going to get much v6 mail delivered without rDNS, because receivers won't even look at your mail to see if it's authenticated.

CenturyLink is reasonably technically clued so it shouldn't be impossible to get them to fix it.

Nothing wrong with my mail server setup, except the lack of RDNS. Lacking reverse should be one of many things to consider with rejecting e-mails, but should not be the only condition. That would be like outright refusing mail unless it had both SPF and DKIM on every single message. Sure, great in theory, does not work in reality and will result in lost mail from legit sources. Already spoken to CenturyLink about RDNS for ipv6 - won't have rdns until native IPv6. Currently, IPv6 seems to be delivered for those who want it, via 6rd. And, frankly, I'm not going to get in a fight with CenturyLink over IPv6 RDNS, considering that I am thankful that they are even offering IPv6 when other large providers aren't even trying to do so to their residential and small business customers. It is very easy for some to forget that not everyone has a gigabit fiber connection to their homes with ARIN assigned IPv4/IPv6 blocks announced over BGP. Some of us actually have to make do with (sometimes very) limited budgets and what the market is offering us and has made available. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org

DMARC says nothing about rDNS, and given how late in the game DMARC comes, it seems like an odd place to enforce rDNS. Local policy, sure; local DMARC policy, wait what? Elizabeth On 3/25/14, 2:12 PM, "Paul Ferguson" <fergdawgster@mykolab.com> wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

Isn't this just a local policy issue with handling DMARC? I know for sure at least one other (very large) organization that (also) rejects messages which do not have an rDNS entry, and it is a local DMARC policy.

- - ferg

On 3/25/2014 1:57 PM, Brielle Bruns wrote:

...

On 3/25/14, 11:56 AM, John Levine wrote:

...

I think this would be a good time to fix your mail server setup. You're never going to get much v6 mail delivered without rDNS, because receivers won't even look at your mail to see if it's authenticated.

CenturyLink is reasonably technically clued so it shouldn't be impossible to get them to fix it.

Nothing wrong with my mail server setup, except the lack of RDNS. Lacking reverse should be one of many things to consider with rejecting e-mails, but should not be the only condition.

That would be like outright refusing mail unless it had both SPF and DKIM on every single message.

Sure, great in theory, does not work in reality and will result in lost mail from legit sources.

Already spoken to CenturyLink about RDNS for ipv6 - won't have rdns until native IPv6. Currently, IPv6 seems to be delivered for those who want it, via 6rd.

And, frankly, I'm not going to get in a fight with CenturyLink over IPv6 RDNS, considering that I am thankful that they are even offering IPv6 when other large providers aren't even trying to do so to their residential and small business customers.

It is very easy for some to forget that not everyone has a gigabit fiber connection to their homes with ARIN assigned IPv4/IPv6 blocks announced over BGP. Some of us actually have to make do with (sometimes very) limited budgets and what the market is offering us and has made available.

- -- Paul Ferguson VP Threat Intelligence, IID PGP Public Key ID: 0x54DC85B2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iF4EAREIAAYFAlMx8VQACgkQKJasdVTchbJkBgD+PeCiFIefgXhmcsyIiqHAdiNX slrBbBk3/edq9yiAsPAA/0zwEwPqfFTyjYvChdgMyC09aSDOFeGT8vf6HZzMCPDt =OHTl -----END PGP SIGNATURE-----