Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space
Mark Andrews wrote:
All IPv6 address assignments are leases. Whether you get the address from a RIR, LIR or ISP. The lease may not be renewed when it next falls due. You may get assigned a different set of addresses at that point. You should plan accordingly.
Exactly the problem, and the reason A) IPv6 is not and will not be a viable option any time soon (soon being before the publication of an IPv6 NAT RFC), and B) why network providers (and other parties who stand to gain financially) are firmly against IPv6 NAT.
If we could get a true accounting of the extra cost imposed by NAT's I would say it would be in the trillions of dollars.
This is exactly the sort of hyperbole, like RFC4864's proposing that application-layer proxies are a viable substitute for NAT, that discredits IPv6 proponents. Those who remember the financial industry's push for SET, a failed encryption technology, will be struck by the similarities in technical vs rhetorical arguments. Perhaps what we need is an IPv6 NAT FAQ? I'm suspect many junior network engineers will be interested in the rational behind statements like: * NAT disadvantage #1: it costs a lot of money to do NAT (compared to what it saves consumers, ILECs, or ISPs?) * NAT disadvantage #2 (re: your IPv6 address space) Owned by an ISP? It isn't much different than it is now. (say again?) * NAT disadvantage #3: RFC1918 was created because people were afraid of running out of addresses. (in 1992?) * NAT disadvantage #4: It requires more renumbering to join conflicting RFC1918 subnets than would IPv6 to change ISPs. (got stats?) * NAT disadvantage #5: it provides no real security. (even if it were true this could not, logically, be a disadvantage) OTOH, the claimed advantages of NAT do seem to hold water somewhat better: * NAT advantage #1: it protects consumers from vendor (network provider) lock-in. * NAT advantage #2: it protects consumers from add-on fees for addresses space. (ISPs and ARIN, APNIC, ...) * NAT advantage #3: it prevents upstreams from limiting consumers' internal address space. (will anyone need more than a /48, to be asked in 2018) * NAT advantage #4: it requires new (and old) protocols to adhere to the ISO seven layer model. * NAT advantage #5: it does not require replacement security measures to protect against netscans, portscans, broadcasts (particularly microsoft netbios), and other malicious inbound traffic. IMHO, Roger Marquis
All IPv6 address assignments are leases. Whether you get the address from a RIR, LIR or ISP. The lease may not be renewed when it next falls due. You may get assigned a different set of addresses at that point. You should plan accordingly.
Exactly the problem, and the reason A) IPv6 is not and will not be a viable option any time soon (soon being before the publication of an IPv6 NAT RFC), and B) why network providers (and other parties who stand to gain financially) are firmly against IPv6 NAT.
A) I think you have a different definition of viable than I do. I have v6 today, running just fine. Not as a home user, yet - but that is coming in the foreseeable future and has nothing to do with the presence of NAT66, or lack thereof. B) I am not a service provider, and I still tend to dis-favor NAT. Not as vehemently as some, but I for the most part, fail to see the need.
If we could get a true accounting of the extra cost imposed by NAT's I would say it would be in the trillions of dollars.
This is exactly the sort of hyperbole, like RFC4864's proposing that application-layer proxies are a viable substitute for NAT, that discredits IPv6 proponents. Those who remember the financial industry's push for SET, a failed encryption technology, will be struck by the similarities in technical vs rhetorical arguments.
While I generally try to avoid the NAT vs NONAT religious debate ... I'll throw in a few comments.
Perhaps what we need is an IPv6 NAT FAQ? I'm suspect many junior network engineers will be interested in the rational behind statements like:
And I suspect lots of new-to-IPv6 network engineers could benefit from more IPv6 exposure :).
* NAT disadvantage #1: it costs a lot of money to do NAT (compared to
what
it saves consumers, ILECs, or ISPs?)
Developed a peer-to-peer application lately? I haven't, but I know some of the issues others have had to go through to work in spite of NAT.
* NAT disadvantage #2 (re: your IPv6 address space) Owned by an ISP? It isn't much different than it is now. (say again?)
Sorry, your befuddlement has passed on to me - I am not sure what you are saying here. The best I can pull from that would be something about PI vs PA space, and I'd comment that both are now available.
* NAT disadvantage #3: RFC1918 was created because people were afraid of running out of addresses. (in 1992?)
Is that a question?
* NAT disadvantage #4: It requires more renumbering to join conflicting RFC1918 subnets than would IPv6 to change ISPs. (got stats?)
* NAT disadvantage #5: it provides no real security. (even if it were
Actually, I think those are different points. NAT-space collisions are a REAL problem, and renumbering due to changing ISPs is also a REAL problem. true
this could not, logically, be a disadvantage)
It is a disadvantage if people believe it is a security thing when it isn't.
OTOH, the claimed advantages of NAT do seem to hold water somewhat better:
* NAT advantage #1: it protects consumers from vendor (network provider) lock-in.
OK, use PI space.
* NAT advantage #2: it protects consumers from add-on fees for addresses space. (ISPs and ARIN, APNIC, ...)
IPv6 addresses (network allocations, actually) are pretty inexpensive ...
* NAT advantage #3: it prevents upstreams from limiting consumers' internal address space. (will anyone need more than a /48, to be asked in 2018)
Yes, /48s have already been outgrown ... so you call up your ISP and justify more, they give it to you. No fuss, no muss.
* NAT advantage #4: it requires new (and old) protocols to adhere to the ISO seven layer model.
Actually, it does more than that. You are thinking of "traditional" network apps, client-server stuff. Think end to end / peer to peer (and I don't mean illegal file sharing) ...
* NAT advantage #5: it does not require replacement security measures to protect against netscans, portscans, broadcasts (particularly microsoft netbios), and other malicious inbound traffic.
Depends on the NAT mode (1:1 or PAT; cone or restricted), and a stateful firewall provides more/real protection ... again, I am not a radical anti-NAT person, I just don't like the pro-NAT hyperbole any more than you favor the opposite :). IMHO /TJ
In message <20090205030522.13D152B21F3@mx5.roble.com>, Roger Marquis writes:
Mark Andrews wrote:
All IPv6 address assignments are leases. Whether you get the address from a RIR, LIR or ISP. The lease may not be renewed when it next falls due. You may get assigned a different set of addresses at that point. You should plan accordingly.
Exactly the problem, and the reason A) IPv6 is not and will not be a viable option any time soon (soon being before the publication of an IPv6 NAT RFC), and B) why network providers (and other parties who stand to gain financially) are firmly against IPv6 NAT.
If we could get a true accounting of the extra cost imposed by NAT's I would say it would be in the trillions of dollars.
This is exactly the sort of hyperbole, like RFC4864's proposing that application-layer proxies are a viable substitute for NAT, that discredits IPv6 proponents. Those who remember the financial industry's push for SET, a failed encryption technology, will be struck by the similarities in technical vs rhetorical arguments.
Perhaps what we need is an IPv6 NAT FAQ? I'm suspect many junior network engineers will be interested in the rational behind statements like:
* NAT disadvantage #1: it costs a lot of money to do NAT (compared to what it saves consumers, ILECs, or ISPs?)
* NAT disadvantage #2 (re: your IPv6 address space) Owned by an ISP? It isn't much different than it is now. (say again?)
* NAT disadvantage #3: RFC1918 was created because people were afraid of running out of addresses. (in 1992?)
* NAT disadvantage #4: It requires more renumbering to join conflicting RFC1918 subnets than would IPv6 to change ISPs. (got stats?)
* NAT disadvantage #5: it provides no real security. (even if it were true this could not, logically, be a disadvantage)
OTOH, the claimed advantages of NAT do seem to hold water somewhat better:
* NAT advantage #1: it protects consumers from vendor (network provider) lock-in.
Nope.
* NAT advantage #2: it protects consumers from add-on fees for addresses space. (ISPs and ARIN, APNIC, ...)
Only until the consumers get wind of any rip-off pricing. RIR's are charging ISP's about the same for a IPv6 /48 as they do the a IPv4 address.
* NAT advantage #3: it prevents upstreams from limiting consumers' internal address space. (will anyone need more than a /48, to be asked in 2018)
We already know some will need more than a /48. /48 was only ever described as meeting the requirements of *most* business and consumers.
* NAT advantage #4: it requires new (and old) protocols to adhere to the ISO seven layer model.
Given were are running IP that is fiticious.
* NAT advantage #5: it does not require replacement security measures to protect against netscans, portscans, broadcasts (particularly microsoft netbios), and other malicious inbound traffic.
What replacement? You just buy a IPv6 router with a firewall. It will be about the same cost as a IPv4 router with a NAT.
IMHO, Roger Marquis
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org
On Wed, Feb 4, 2009 at 10:45 PM, Mark Andrews <Mark_Andrews@isc.org> wrote:
In message <20090205030522.13D152B21F3@mx5.roble.com>, Roger Marquis writes:
Mark Andrews wrote:
All IPv6 address assignments are leases. Whether you get the address from a RIR, LIR or ISP. The lease may not be renewed when it next falls due. You may get assigned a different set of addresses at that point. You should plan accordingly.
Exactly the problem, and the reason A) IPv6 is not and will not be a viable option any time soon (soon being before the publication of an IPv6 NAT RFC), and B) why network providers (and other parties who stand to gain financially) are firmly against IPv6 NAT.
What about costs? If you're a realist, you know that v6 migration is a cost problem. Ask cable or DSL providers across the world what percentage of their user base CPE is v6 compatable and the answer will likely be shocking. In this economy, unless the seondary market is egregiously expensive, don't expect to see a mass migration. There's also the problem of no known commericial grade NAT device (SLA worthy) that makes this easier. Thoughts appreciated. Best, Martin -- Martin Hannigan martin@theicelandguy.com p: +16178216079
On Wed, Feb 4, 2009 at 10:45 PM, Mark Andrews <Mark_Andrews@isc.org> wrote:
We already know some will need more than a /48. /48 was only ever described as meeting the requirements of *most* business and consumers.
so.. what businesses need is not actually 'more than one /48' but real, useful, doable multihoming. A /48 is fine if you have only one site, it's been used to solve 2 of 3 problems: 1) my addresses don't have to change (if I only have one site) 2) I can multihome with a single address on my devices/hosts (cause the original v6 plan for that was just dumb) It doesn't solve the problem of an enterprise with more than one location/network-interconnect... we can go around this rose bush again and again and again, but honestly, deployment of v6 happens for real when there is a significant business reason to deploy it, and when the real concerns of enterprises today are actually addressed. -Chris
It doesn't solve the problem of an enterprise with more than one location/network-interconnect... we can go around this rose bush again and again and again, but honestly, deployment of v6 happens for real when there is a significant business reason to deploy it, and when the real concerns of enterprises today are actually addressed.
Indeed, and the IETF's answer for multi-homing (SHIM6) is a non-starter for the majority of those interested in doing so. Enter PI space, now available from (most of) your local RIR(s). Yes, also enter DFZ growth ...
On Feb 5, 2009, at 7:41 AM, TJ wrote:
It doesn't solve the problem of an enterprise with more than one location/network-interconnect... we can go around this rose bush again and again and again, but honestly, deployment of v6 happens for real when there is a significant business reason to deploy it, and when the real concerns of enterprises today are actually addressed.
Indeed, and the IETF's answer for multi-homing (SHIM6) is a non- starter for the majority of those interested in doing so. Enter PI space, now available from (most of) your local RIR(s). Yes, also enter DFZ growth ...
That is an answer, not the answer. You might be interested in the discussion around LISP (routing, not language). http://www.ietf.org/mail-archive/web/lisp/current/msg00070.html https://www.ietf.org/mailman/listinfo/lisp Regards Marshall
On Thu, Feb 5, 2009 at 7:41 AM, TJ <trejrco@gmail.com> wrote:
It doesn't solve the problem of an enterprise with more than one location/network-interconnect... we can go around this rose bush again and again and again, but honestly, deployment of v6 happens for real when there is a significant business reason to deploy it, and when the real concerns of enterprises today are actually addressed.
Indeed, and the IETF's answer for multi-homing (SHIM6) is a non-starter for
to be fair, there are 3 options for multihoming today in v6 (three sanctioned by the IETF, not ordered in any order, not including discussion about goodness/badness/oh-god-no-ness of these) 1) multiple addresses on each device, one per provider 2) shim-6 3) HIP (still in development, as I recall) These don't address how the network is used today, nor customer requirements for enterprises nor operational concerns about running a network.
the majority of those interested in doing so. Enter PI space, now available from (most of) your local RIR(s).
sure, you can get PI /48's or up to something >= /40's... but, you are expected to not deaggregate these, and I suspect there will be issues when you attempt to do so with reachability.
Yes, also enter DFZ growth ...
hurrah! :( -Chris
On 5-Feb-2009, at 06:34, Christopher Morrow wrote:
to be fair, there are 3 options for multihoming today in v6 (three sanctioned by the IETF, not ordered in any order, not including discussion about goodness/badness/oh-god-no-ness of these) 1) multiple addresses on each device, one per provider 2) shim-6 3) HIP (still in development, as I recall)
4) Obtain PA space and do what you're doing with v4. 5) Obtain PI space and do what you're doing with v4. (4) is problematic because filtering long prefixes in v6 seems to be more energetic than it is in v4. (5) is problematic if you don't qualify for PI space. (For completeness.) Joe
Joe Abley wrote:
4) Obtain PA space and do what you're doing with v4.
5) Obtain PI space and do what you're doing with v4.
(4) is problematic because filtering long prefixes in v6 seems to be more energetic than it is in v4. (5) is problematic if you don't qualify for PI space.
As more people are pushed to IPv6, I see the longer prefixes being allowed more. The problem with the other options, while wonderful, is that they require end node support. There is no guarantee the end nodes will support shim6. This means to have proper redundancy, we'll still have to use the routing protocols. If I'm wrong, please correct me. This is a good concern. Jack
On 5 feb 2009, at 20:06, Joe Abley wrote:
4) Obtain PA space and do what you're doing with v4.
5) Obtain PI space and do what you're doing with v4.
(4) is problematic because filtering long prefixes in v6 seems to be more energetic than it is in v4. (5) is problematic if you don't qualify for PI space.
Better hope the RRG work (LISP, maybe) works out, then. I'm sure some people will relax their filters but I'm also convinced that a lot of people won't, at least not until a consensus on a good prefix length filtering strategy emerges. The RIR policies are such that if you allow /48s you're dead in the water if someone tries to inject a large number of those on purpose or it happens by accident in a particular unfortunate way. The reason I think people won't accept long prefixes is because of the above, or because (like me) they feel IPv6 PI was a mistake, or, the main contributor to routing table bloat, laziness. And the reason they won't care is that if an IPv6 destination returns !N applications that try both IPv6 and IPv4 fall back on IPv4 without a noticeable delay so outgoing sessions aren't affected. (Incoming sessions have to time out though, no ICMPs back to the originator for those.)
On Feb 5, 2009, at 11:06 AM, Joe Abley wrote:
On 5-Feb-2009, at 06:34, Christopher Morrow wrote:
to be fair, there are 3 options for multihoming today in v6 (three sanctioned by the IETF, not ordered in any order, not including discussion about goodness/badness/oh-god-no-ness of these) 1) multiple addresses on each device, one per provider 2) shim-6 3) HIP (still in development, as I recall)
4) Obtain PA space and do what you're doing with v4.
5) Obtain PI space and do what you're doing with v4.
(4) is problematic because filtering long prefixes in v6 seems to be more energetic than it is in v4. (5) is problematic if you don't qualify for PI space.
Note, however, that the bar for (5) is VERY low if you are multi-homed. I would not be opposed to lowering it even further, but, there does not at this time seem to be community consensus to do so. Owen
Once upon a time, Roger Marquis <marquis@roble.com> said:
* NAT advantage #5: it does not require replacement security measures to protect against netscans, portscans, broadcasts (particularly microsoft netbios), and other malicious inbound traffic.
Since NAT == stateful firewall with packet mangling, it would be much easier to drop the packet mangling and just use a stateful firewall. You are just reinforcing the incorrect belief that "NAT == security, no-NAT == no-security". -- Chris Adams <cmadams@hiwaay.net> Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
On 4-Feb-2009, at 19:05, Roger Marquis wrote:
Mark Andrews wrote:
All IPv6 address assignments are leases. Whether you get the address from a RIR, LIR or ISP. The lease may not be renewed when it next falls due. You may get assigned a different set of addresses at that point. You should plan accordingly.
Exactly the problem,
In the regional ISP I alluded to in my previous message, /56es are assigned to residential DSL customers and are static (they are handed out to the LNS from RADIUS). The link address (IPV6CP + ND/RA) depends on the particular LNS your PPP session lands on, however.
and the reason A) IPv6 is not and will not be a viable option any time soon (soon being before the publication of an IPv6 NAT RFC), and B) why network providers (and other parties who stand to gain financially) are firmly against IPv6 NAT.
In this case there is no religion for or against NAT inherent in the v6 access service being provided. Customers can do what they want with the addresses provided to them. Joe
On Wed, 4 Feb 2009, Roger Marquis wrote:
Perhaps what we need is an IPv6 NAT FAQ? I'm suspect many junior network engineers will be interested in the rational behind statements like:
* NAT disadvantage #1: it costs a lot of money to do NAT (compared to what it saves consumers, ILECs, or ISPs?)
Yes it cost more money in OPEX. Try to detect malicious host behind a NAT among thousand of hosts.
* NAT disadvantage #3: RFC1918 was created because people were afraid of running out of addresses. (in 1992?)
Yes. One of my colleague, who participated in development of RFC 1918 confirmed it.
* NAT disadvantage #4: It requires more renumbering to join conflicting RFC1918 subnets than would IPv6 to change ISPs. (got stats?)
This statement is true: Currently you encounter more private address usage than IPv6 usage.
* NAT disadvantage #5: it provides no real security. (even if it were true this could not, logically, be a disadvantage)
It is true. Lots of administrator behind the NAT thinks, that because of the NAT they can run a poor, careless software update process. Majority of the malware infection is coming from application insecurity. This cannot be prevented by NAT!
OTOH, the claimed advantages of NAT do seem to hold water somewhat better:
* NAT advantage #1: it protects consumers from vendor (network provider) lock-in.
Use PI address and multi homing.
* NAT advantage #2: it protects consumers from add-on fees for addresses space. (ISPs and ARIN, APNIC, ...)
No free lunch. Or use IPv6.
* NAT advantage #3: it prevents upstreams from limiting consumers' internal address space. (will anyone need more than a /48, to be asked in 2018)
You can gen more /48, or use ULA.
* NAT advantage #4: it requires new (and old) protocols to adhere to the ISO seven layer model.
This statement is a bullshit.
* NAT advantage #5: it does not require replacement security measures to protect against netscans, portscans, broadcasts (particularly microsoft netbios), and other malicious inbound traffic.
Same, if your implement proper firewall filtering. Best Regards, Janos Mohacsi
* NAT disadvantage #3: RFC1918 was created because people were afraid of running out of addresses. (in 1992?)
Yes. One of my colleague, who participated in development of RFC 1918 confirmed it.
Your colleague was wrong. I was one of several engineers who handed out "private" addresses back before RFC1918 even though we could get "public" assignments. We did it for SMBs, large law firms, even departments of companies that were otherwise publically addressed. Nobody expressed concern for the size of the address pool (this was 1993 after all, only a year or two after uunet and psi made it possible to connect). You can confirm this by looking for references to address exhaustion in periodicals and usenet archives. It was simply not an issue until 95 or 96 at the earliest. The reason we used non-routable addresses was security and privacy. These subnets had no intention of ever communicating with "the Internet" directly. Web browsers changed that equation but the original business case for security and privacy has not changed. That business case is also why several of those otherwise legally addressed companies and departments switched to rfc1918, also before anyone gave a thought to address exhaustion.
* NAT disadvantage #5: it provides no real security. (even if it were true this could not, logically, be a disadvantage)
It is true. Lots of administrator behind the NAT thinks, that because of the NAT they can run a poor, careless software update process. Majority of the malware infection is coming from application insecurity. This cannot be prevented by NAT!
Can you site a reference? Can you substantiate "lots"? I didn't think so. This is yet another case the rhetoric gets a little over the top, leading those of us who were doing this before NAT to suspect a non-technical agenda. Roger Marquis
On Thu, 05 Feb 2009 08:24:16 PST, Roger Marquis said:
Can you site a reference? Can you substantiate "lots"? I didn't think so. This is yet another case the rhetoric gets a little over the top, leading those of us who were doing this before NAT to suspect a non-technical agenda.
Some estimates say that Conficker has nailed over 9 to 16 million systems by now. Every single one was because somebody didn't apply a patch that came out back in October. I'm sure at least some of these were because of either: a) "I'm Joe Sixpack, and I'm safe because I'm behind my cablemodem" b) "I'm Joe McSE (want fries with that?), and I'm safe because of the corporate firewall". (Note that due to its design, Conficker *can't* spread through a properly configured firewall - almost by definition, *every single* firewalled network that got hit was because somebody forgot the difference between "firewall" and "security perimeter".
On Feb 5, 2009, at 8:24 AM, Roger Marquis wrote:
* NAT disadvantage #3: RFC1918 was created because people were afraid of running out of addresses. (in 1992?)
Yes. One of my colleague, who participated in development of RFC 1918 confirmed it.
Your colleague was wrong. I was one of several engineers who handed out "private" addresses back before RFC1918 even though we could get "public"
You are wrong.... Quoting from RFC 1597 (a precursor which was obsoleted by RFC 1918): 2. Motivation With the proliferation of TCP/IP technology worldwide, including outside the Internet itself, an increasing number of non-connected enterprises use this technology and its addressing capabilities for sole intra-enterprise communications, without any intention to ever directly connect to other enterprises or the Internet itself. The current practice is to assign globally unique addresses to all hosts that use TCP/IP. There is a growing concern that the finite IP address space might become exhausted. Therefore, the guidelines for assigning IP address space have been tightened in recent years [1]. These rules are often more conservative than enterprises would like, in order to implement and operate their networks. Note the specific reference in the second paragraph to address space exhaustion. Owen
participants (13)
-
Chris Adams -
Christopher Morrow -
Iljitsch van Beijnum -
Jack Bates -
Joe Abley -
Mark Andrews -
Marshall Eubanks -
Martin Hannigan -
Mohacsi Janos -
Owen DeLong -
Roger Marquis -
TJ -
Valdis.Kletnieks＠vt.edu