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.

  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.

2

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

3

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

4

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

5

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

6

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

-Chris

7

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

8

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

9

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

10

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