Keith Moore - le (m/j/a) 4/10/09 3:14 AM:
I continue to believe that if a host has multiple addresses (for
whatever reason) then things work best if the application can learn
that it has multiple addresses at which it can be reached, and
multiple addresses from which it can source traffic, and it knows
what they are. Trying to hide these things from the apps is a big
part of what breaks them, and it certainly makes it more difficult to
fix the apps to work under those conditions.
I agree that applications should _be able_ to know about their possibly
multiple addresses.
But I also believe that SCTP and SHIM6 should work with several local
addresses, without applications having to be aware of it.
There was also some grousing when I mentioned that we don't think
address amplification is a worthy goal for any new 6AI standards
effort. They've grown quite accustomed to using asymmetric
translation to conserve address space in various parts of their
network, and they're worried that its lacking in NAT66 will be a
source of additional headache for them.
I suspect it does mean that network operators have to manage
addresses subtly differently than they have in the past. E.g.
instead of trying to build a deep hierarchy of address
allocation/delegation, they might find it works better to make the
delegation hierarchy shallow. The good news is that even if you only
have a /48, you can still address 2**16 LANs, give each of them a
/64, and put as many hosts on each of those LANs as you can stand,
without running out of addresses on any of those LANs. (and if you
have more than 2**16 LANs you ought to be able to get at least
another /48 if not a shorter prefix).
Many personal computers can establish LANs behind them, and/or can run
several internal virtual machines (what I call "host-rooted subnets").
Let's assume such a host is on a /64 link, with a /128 address.
If a bridge function in the host is not possible (e.g. because of a
different LAN standard behind the host) or not desirable (e.g. for
multicast isolation), then some sort of NAPT66 is the most
straightforward solution so far for hosts behind the host to have IPv6
outgoing connectivity.
They really like their NAPT gateways, and the thought of planning
to go without them into combat leaves them far, far away from their
happy comfort zone. I wish I knew how to soothe their nerves.
Draft-despres-sam-02 presents a general approach that, for hosts that
can be modified, eliminates the need to use NAPT66s and restores e2e
transparency.
Soothing these people's nerves is likely to take time, but less if we
make the necessary steps in the necessary direction.
I keep telling people that IPv6 is a lot more different than IPv4
than they think. A lot of the conventional wisdom from IPv4 doesn't
apply. But it's hard to get people to see that, and I think it will
take a few years of actual experience before network operators in
general start to get it.
In my understanding, the essential difference is that with 128-bit
addresses it is possible to assign _global addresses to all hosts_, even
at the leafs of a long hierarchy of independently administered routing
zones. E2e transparency, and simple referrals, which were part of the
initial Internet model can thus be restored.
If done right, traversal of private-addressing realms can be supported,
as well as multihoming at various points of the routing hierarchy.
To really take advantage of 128-bit addresses, the work in IMHO _not
finished_: some constraints that are stronger than needed in many
useful configurations need to be relaxed (very carefully indeed, but
relaxed).
Among them, we have:
- /48s to all customer sites (easily relaxed)
- 64-bit IIDs in all global unicast addresses (less easily relaxed, but
IMHO with a great potential).
I hope that the number of reactions to the current SAM proposal will
increase(www.ietf.org/internet-drafts/draft-despres-sam-02): it's the
result of a significant effort to tackle this subject with a global view.
Regards,
RD
_______________________________________________
nat66 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nat66
