RE: ocean: do not boil

[Margaret Wasserman <mrw@windriver.com>]

Hi Hesham,

> => I think we're drifting from the main issue
> a little bit. Here is a scenario that I'd like
> to understand how it would work:
> What do we recommend a new small 3g operator who only
> has 10 million subscribers (just a small town
> in china!) and wants to allow people to run p2p apps:
>
> a. Run a dual network with 1918 addresses
> b. Just run an IPv6 network
>
> If people want to do a), do you really think
> this would be simpler than b) ? Easier to manage
> and operate?
I've been thinking about this question and trying to
come up with a good answer...

I'm actually thinking of this question a bit differently,
so please tell me if it matches what you are asking:

What is the best way to set-up a network of 10 million
nodes that all to need access both IPv6-only and IPv4-only
services?

There are two thoughts that I have about this question:

        (1) It isn't a fully qualified question.
                Further information is needed to
                for a complete answer, such as:

                - Do these nodes need continuous access
                        to IPv4 and IPv6 services, or only
                        occasional access?
                - How many simultaneous IPv4 & IPv6
                        connections are expected?
                - What is the planned internal structure
                        of the network?  Obviously you aren't
                        planning to bridge 10 million nodes
                        on a single subnet.

        (2) Neither IPv4 nor NAT-PT will handle a 10 million
                node network as a single address space.
                The limitation of 32-bit addressing in IPv4
                is a red herring, since the real limitations
                on the size of a NAT based network is probably
                much lower (a few hundred thousand simultaneous
                connection?).

But, given that you've said this is a 3GPP network, I can
make some (perhaps flawed) assumptions about how this network
will be structured:

        (1) There will be internal routers (GGSNs) at a
                density of one per ~100,000-500,000 nodes.
        (2) All nodes will have point-to-point connections
                to a single router (PDP Contexts to the GGSN).
        (3) The nodes will only need occasional access to
                IPv4 & IPv6 services.
        (4) IPv4 address configuration (and IPv6 address
                configuration) of the nodes will
                be performed on an as-needed basis
                via the establishment of PDP contexts.

In this case, I would suggest that any address translation
(IPv4 or IPv6) be performed on a per-GGSN basis, with the
NAT either co-resident in the GGSN or sitting directly
behind it (between the GGSN and the rest of the Internet).

So, really we are comparing two things:

        (A) The complexity, effort and effectiveness of
                configuring the GGSNs as IPv6-only routers
                and running a NAT-PT box per GGSN to
                translate selected IPv6 traffic into
                IPv4 traffic.  This would allow the end-nodes
                to be IPv6-only, but would require them to
                have some special DNS resolution/literal
                IPv4 address handling mechanisms.

        (B) The complexity, effort and effectiveness of
                configuring the GGSNs as IPv4/IPv6 routers,
                running an IPv4 NAT box per GGSN, and
                having the GGSNs allocate RFC 1918
                addresses on PDP contexts.  This would
                require any nodes that need to reach
                IPv4-only services to include IPv4 and
                any nodes that need to reach IPv6-only
                services to include IPv6 (nodes that need
                to reach both would need to be dual stack).

There are a few key differences between these choices:

Choice A has the advantage that it only requires a
single stack on the end-nodes, which may save a little
bit of memory... However, IPv4 and IPv6 stacks share a
large portion of their code, so this will be a small
savings.

Choice A only supports IPv6-only end-nodes.  It won't
be possible to set-up an IPv4 PDP context, and two nodes
that are behind the same GGSN will not be able to
establish an IPv4 connection to each other.  Is that
okay?

Choice A may also have some new (i.e. not present in
the IPv4 network today) architectural issues running
IPv4 applications caused by:

        - The DNS resolver/IP address interpretation
                machinations on the local box.
        - The availability of IPv4<->IPv6 ALGs for
                whatever applications the host is
                using.

Choice B will support IPv4-only, IPv4/IPv6 dual stack
and IPv6-only nodes, will allow nodes to use IPv6 and
IPv4 PDP contexts, and will support IPv4 connections
between nodes attached to the same GGSN.  Are any of
these things needed?

Choice B will also have the best chance of supporting
all IPv4-only services that work in a NAT-based network
today.

I agree that Choice B may be marginally more complex
to set-up and maintain than Choice A...

So, there is a pretty complex trade-off here, but if
I had to choose for my own network, I'd probably go
with the dual-stack parallel IPv4/IPv6 network approach.

I wish that I really understood the DSTM/DHCP choice
well enough to explain how it could/couldn't fit into
this situation...  I'm working up to that now.

Margaret