On Jul 13, 2007, at 10:57 AM, Hallam-Baker, Phillip wrote:
I think we need to look beyond whether NAT is evil (or not) and
whether NATPT is the solution (or not) and look to see how we might
manage a transition to IPv6 in a way that is not predicated on
holding ISP customers hostage.
People have been there and done that, anyone remember when the anti-
spam blacklists started talking about 'collateral damage' with
great glee? Within a very short time a very large number of email
admins hated the self appointed maintainers of the blacklists more
than the spammers.
Anyone with a published mailbox not protected by a blocking strategy
quickly learns email is dysfunctional. Lost DSNs of silently
discarded messages, or messages directed to a junk folders never
reviewed are all too common problems. Black-hole lists bounded by AS
CIDR ranges is not a gleeful strategy. Some ISPs host servers
involved in nefarious activities and reassign addresses periodically
to thwart a per address blocking strategy.
To disabuse unfair accusations of abusing the service, we will offer
a full range of blocking strategies freely selected by each
customer. Customers can then find their optimal balance between
filtering and IP address blocking techniques of which there are
many. Unfortunately, few filtering applications alone are able to
handle the current level of abuse without address black-holing. And
unfortunately, offering a more graduated approach increases the level
of abuse seen on the Internet as a whole.
IPv6 will not make this problem go away. IPv6 will necessitate
development of a means to positively verify the administrative domain
of the _client_ sending traffic into the public address space before
the transition to IPv6 can be embraced by existing public messaging
services.
We have three Internets: IPV4, IPv4+NAT and IPv6.
Perhaps this breakdown should include these perspectives as well.
IPv6+6to4, IPv6+NAT.
This strongly suggests to me that during the transition, a period I
expect to last until 2025, we will want the standard Internet
allocation to be a /64 of IPv6 plus a share in a pool of IPv4
addreses behind a NAT.
The correlation of IPv6 addresses within IPv4 space might be
dynamically assigned by newer services, such as PNRP. NATs will
remain a part of the Internet long into the foreseeable future,
regardless of what might be said or done. Perhaps new types of DNS
records need to be developed to express complex paths now required by
today's applications operating within the reality of mixed
topologies. Such navigation will likely be handled at what might be
seen as new sub-layers.
What I would like to get to is a situation where a consumer can
1) purchase Internet connectivity as a commodity with a well
defined SLA that assures them that the connection will work for the
purposes they wish to use it
2) obtain a report from their Internet gateway device(s) that tells
them whether the SLA is being met or not.
When an ISP permits their customers to abuse the Internet, recipients
of this abuse MUST BE ALLOWED to block abusive traffic. These blocks
will not disappear quickly, nor are these blocks directly managed by
ISPs offering now blocked outbound connectivity. A customer of such
an ISP may have no recourse, but to seek different providers
regardless of what is within their SLA. There is no need to receive
a report, the customer will be aware of the problem rather quickly.
Perhaps this can be solved by offering a "tasting" period. ; )
From the point of view of the consumer all that matters is that
their client applications and their peer-2-peer applications work.
The typical consumer does not host servers at their home and we
want the sophisticated consumer to move to IPv6.
Consumers often violate the AUP of their residential Internet
provider. Acknowledging this, some AUPs are making exceptions where
semi-private versus public server use might be allowed. These
exceptions often permits things like remote access or various peer-to-
peer applications. These applications are fairly common and
supported by various mechanisms included in typical IPv4 wireless
routers.
Most application protocols work just fine behind NAT. FTP works
with an ugly work-around. The main protocol that breaks down is
SIP. I am mighty unimpressed by the fact that when I plug the VOIP
connector made by vendor X into the wirless/NAT box made by vendor
X that I have to muck about entering port forwarding controls by
hand. And even less impressed by the fact that a good 50% of the
anti-NAT sentiment on this list comes from employees of vendor X.
STUN does not appear to me to be an architecturally principled
approach, it is a work around.
Techniques employed to navigate through NAT and firewall barriers are
often based upon various assumptions. The small percentage of cases
where the assumptions prove wrong causing techniques fail, will
consume a disproportionate amount of customer support. Even when
applications fail within a small percentage of network environments,
these failures are also likely to cause the application to fail
within the marketplace.
The way to fix this situation in my view is to make the NAT box SIP
aware by building a SIP proxy capability into the NAT box. The
designers of NAT boxes go to great efforts to try to work around
applications. Leave approaches such as STUN to the case where you
are dealing with a legacy box.
There should concern about SIP abuse when switching is placed within
a typical NAT. This would likely cause consumers to confront an
abuse problem that is difficult to solve. Their recourse might be to
simply disable their service and utilize centralized services which
often offer PSTN connectivity as well.
-Doug
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf