ietf
[Top] [All Lists]

Re: IPv4 to IPv6 transition

2007-07-14 14:48:24

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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf