[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Follow-up work on NAT-PT - a new approach

John,

On 2007-11-09 12:27, John Curran wrote:

At 11:25 AM +1300 11/9/07, Brian E Carpenter wrote:

I would envisage a similar approach for an ISP supporting
SOHO subscribers - that really isn't much different from
a campus network. The ISP will need dual-stack mail servers,
for example. Anyone providing services to the public will need
a dual stack, for that matter, if they want to be accessible.


At some point, ISP's will: 1) Be unable to readily obtain additional
IPv4 address space, 2) Want to keep growing, and 3) Want a
method for connecting up customers via IPv6-only which provides
some semblance of full Internet connectivity (including backward
reachability to IPv4 destinations).


Clearly!




From the ISP point of view, some of the key requirements are:


 - Has to require a minimal amount of special per-site
   (or per-site-host) configuration in order to provide
   the connectivity to Internet IPv4-only sites.


Sure. Assuming the ISP is running dual-stack routing, I believe
they'll need to configure things like mail and web servers
as dual-stack, and IM servers if they're offering that, but it's
hard for me to imagine that a local ISP will ever be able to solve
the problem of an IPv6-only subscriber accessing an IPv4-only Bloop server
on another continent, for arbitrary values of Bloop, unless there is
some help from the IPv6 host stack as well as a magic translator
box. (And this has nothing to do with IPv6 design details -
once you're sending packets that the IPv4-only server wasn't designed
to receive, you automatically have this problem.) I think we've
spent too long hoping that the world can be either pure IPv6-only
or pure dual stack - to solve this problem we need the IPv6-only
stack to be a little impure.


 - Allow for sharing of some IPv4 space that the ISP
   has set aside for such purposes.


Yes, which is why SHANTI includes NAPT-like port mapping.



 - Allow implementation of the same "site" policies
   (such as port-based firewall filters) on the IPv4
   backward-compatible connectivity that customers
   use today to provide nominal security.


I can't see why that would be an issue. Ports work pretty
much the same in v4 and v6, and as noted, at least in my
proposal ports are handled exactly as in NAPT.



Contrary to what a lot of folks think, I don't think that the
backwards-compatibility IPv4 connectivity really needs to
be general purpose, or application friendly, or support a
truly end2end model. 

But if it doesn't support *unknown* or even *future* applications,
it is going to cause help desk calls (probably insoluble help
desk calls, too). I realise that NAT does that today, but surely
we'd like to do better?


While NAT-PR is indeed imperfect
(as documented in RFC4966), it still provides minimal
backwards connectivity that is going to be desperately
needed for many providers.


However, for the residual cases, it's precisely because
of the issues with NAT-PT that I've just started working
on SHANTI. Whether that's of value is for the community
to say.


If there's a way to improve the resulting connectivity
without create a raft of customer configuration and
support issues, it's probably of value to the community.


As far as I can see the configuration issues aren't major.
All user systems served by the same SHANTI translator will
need to know its IPv6 and IPv4 address by configuration -
Yet Another DHCP Option could provide that. The
translator itself would be exactly where you'd put a NAT
and firewall today, and would be configured just like a NAPT.
No free lunch, of course.

    Brian