[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: ocean: do not boil
Hi Margaret,
The DHCP DSTM choice would work as follows:
It would assume your choice B below.
At the GGSN it would be able to forward
IPv4 packets that were encapsulated in IPv6,
when the handheld wanted to speak to IPv4 apps.
But we need to discuss 1918 address and global
IPv4 address space.
If 1918 then I would argue the only use for
DSTM is behind the GGSN to the UE device (e.g.
local 3G provider services) or if the services from
the GGSN were within a private 1918 network then
the IPv4 packets could be used to get to those
services using 1918 addresses. But DSTM could
also provide global Ipv4 addresses if as one of
your questions/assumptions was that IPv4
is needed for only temporary or limited use
of network services.
At the UE or handheld lets assume it mostly
speaks IPv6 for IM in 3G. When it needs
v4 address the dhcpv6 client or a more light
weight mechanisms requests a DSTM address
(private or global) to speak IPv4.
The IPv4 address then is encaped to the
GGSN DSTM Edge Router and then forwarded..
The GGSN DSTM router would have to send the IPv4
back thru the IPv6 core network would have to have
a mapping of how to get back to the v6 UE/handheld via
encaping v4 in v6.
This is only useful when IPv4 is being used as limited
for services or special apps that have not been ported.
DSTM assumes strongly that v6 is the dominant deployment
strategy. Once that happens all the e2e pain can be avoided
that one gets with NAT and e2e security/vpns are possible
with IPv6.
Now dhcpv4 could be used but that means the handheld
is running IPv4 dhcp client. That means its running a dual
stack for services. DSTM does not require this and why
we put DSTM options in dhcpv6 for the case where the
client only wants to run IPv6 and IPv4 as special operation.
The overall DSTM architecture is to avoid NAT completely
where it might be used by IPv6 nodes.
DSTM does assume that nodes are dual stacked though.
regards,
/jim
> -----Original Message-----
> From: Margaret Wasserman [mailto:mrw@windriver.com]
> Sent: Sunday, September 29, 2002 8:55 PM
> To: Hesham Soliman (EAB)
> Cc: 'itojun@iijlab.net'; v6ops@ops.ietf.org
> Subject: RE: ocean: do not boil
>
>
>
> 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
>
>
>
>
>
>
>
>
>
>