[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Follow-up work on NAT-PT
On Mon, 12 Nov 2007 00:53:57 -0500 (EST)
briand@ca.afilias.info wrote:
> Margaret wrote (very concisely, I might add):
>
> > Exactly what types of operational problems exist that we need to
> > solve? Why aren't the existing v4/v6 transition mechanisms
> > sufficient to resolve those problems? Where are the gaps that needs
> > to be filled?
>
> Here are what I perceive (not just personally, but from a variety of
> input e.g. at NANOG, ARIN meetings in ABQ):
>
> 1) IPv4 access of *some* flavor from end-networks when end networks no
> longer have the ability to get their own IPv4 space (which precludes use
> of public IPv4 in a dual-stack environment)
As people have already chosen not to get enough of their own IPv4
address space, i.e. have used RFC1918 addressing instead of giving all
their devices a world wide unique IPv4 address, solutions to this
problem have already been developed and deployed - NAT/NAPT and ALGs such as web
proxies.
> 2) Support for (1) from a large ISP perspective when the end-user or
> end-network connectivity is not dual-stack
NAT/NAPT and ALGs can do that with RFC1918, and of course, already are.
> 3) Support for all of the above when the end nodes number greater than the
> number of IPs available under RFC 1918 (i.e. more IPs than one instance of
> all private addresses can cover)
How common will this case be? I'm only aware of one organisation who's
having this problem, and that is a cable Internet company, and I'm
guessing their problem is with their OAM private addresses for the CPE
- I'd assume they've given the subscriber side of the CPE public
addresses. While I don't know much about their situation, if it is
plain cable CPE TFTP provisioning, I think they could address this
problem by accepting less than full OAM reachability inside their
network - having multiple OAM domains where each domain has it's own
instance e.g. of 10/8. Theirs is a corner case, and their issue isn't an
Internet connectivity / Internet application problem.
1 x "Class A", 16 x "Class B", and 256 x "Class C"s is an awful lot of
private address space that could be used with web proxies and ALGs. Do
you think ISPs would go to such extreme efforts to avoid deploying
IPv6 that they'd approach exhausting the RFC1918 address space? I'd
suggest they'd probably have gone out of business by then, as their
customers would have abandoned them for their competitors who're providing
"better Internet" by using IPv6.
Regards,
Mark.
>
> What is *not* needed, IMHO, is any-any IPv4 over the above connection
> requirments, e.g. the presumption is any two boxes above will be able to
> see each other via IPv6 directly, so P2P stuff should work okay, and the
> existing techniques for v4-only apps via private p2p ad-hoc ipv4 over ipv6
> tunnels should be presumed to work fine.
>
> The presumption should be:
> clients accessing servers, where servers are IPv4, and clients are ipv6,
> and the predominant component of the access side of the clients, including
> possibly their ISP, and even their ISP's ISP, is v6 only.
>
> (Please see my reply to Brian Carpenters query, several days ago, I will
> flesh it out some more, but IPv4-IPv6-IPv4-IPv4NAT-(Internet-v4) with PT,
> may be an ugly hack with good scaling characteristics and the ability to
> do port-specific ALGs in a way that allows ISP/ISP support for ALGs, i.e.
> very attractive scaling characteristics.
>
> Brian D
>
> > I really have no doubt that we could build a purer, cooler, "better"
> > version of NAT-PT. In fact, I even have my own thoughts on how we
> > could do that. But without understanding exactly what problem(s) we
> > are trying to solve, I don't think that will be a very useful exercise.
> >
> > Margaret
> >
> >
> > On Oct 28, 2007, at 7:48 PM, Brian E Carpenter wrote:
> >
> >> On 2007-10-14 06:28, Jari Arkko wrote:
> >>> Thanks for this, Olaf. Indeed, we are considering follow-up work,
> >>> and understanding the scenarios & possible need for producing
> >>> a revised version of NAT-PT is on the Vancouver agenda (currently
> >>> planned to be a discussion in V6OPS, with protocol work to fall
> >>> out to an INT area WG).
> >>
> >> I realise this may be jumping the gun a bit, but since I won't be
> >> in Vancouver, here is a sketch of one possible direction.
> >>
> >> Brian
> >>
> >> -------- Original Message --------
> >> Subject: I-D Action:draft-carpenter-shanti-00.txt
> >> Date: Sun, 28 Oct 2007 18:20:01 -0400
> >> From: Internet-Drafts@ietf.org
> >> Reply-To: internet-drafts@ietf.org
> >> To: i-d-announce@ietf.org
> >>
> >> A New Internet-Draft is available from the on-line Internet-Drafts
> >> directories.
> >>
> >> Title : Shimmed IPv4/IPv6 Address Network Translation
> >> Interface (SHANTI)
> >> Author(s) : B. Carpenter
> >> Filename : draft-carpenter-shanti-00.txt
> >> Pages : 12
> >> Date : 2007-10-28
> >>
> >> There is a pragmatic need for a packet-level translation mechanism
> >> between IPv4 and IPv6, for scenarios where no other mode of IPv4 to
> >> IPv6 interworking is possible. The mechanism defined here uses a
> >> shim in both the translator and the IPv6 host to mitigate the
> >> problems introduced by stateless translation.
> >>
> >> A URL for this Internet-Draft is:
> >> http://www.ietf.org/internet-drafts/draft-carpenter-shanti-00.txt
> >>
> >
> >
> >
>
>
>