v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space

Mailman List Mirror (Read Only)
1

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

2

  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?)

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.

* NAT disadvantage #5: it provides no real security. (even if it were

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

3

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

4

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

5

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

6

* 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

7

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

8

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