Subject: RE: NATs as firewalls

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 7 Mar 2007 16:23:20 -0800

Quite, the dissappearance of un-NATed IPv4 is inevitable.

Regretably the ready availability of IPv6 is not.

There are two possible future outcomes here. The first is that the only widely available option is NAT-ed IPv4. The second is a dual stack offering that combines NAT-ed IPv4 with full feature IPv6.

We do need to revise the architecture description. Using IP addresses as implicit signalling is bad. Another instance that hit me today is the fact that existing SSL implementations use the server IPv4 address to select which server certificate to present to a client. This means that if you want to multi-home multiple SSL sites on one box you need to burn an IPv4 address for each. EKR told me there is a solution but again we have to get people to use it.

> -----Original Message-----
> From: Darryl (Dassa) Lynch [mailto:[email-masked]] 
> Sent: Wednesday, March 07, 2007 3:53 PM
> To: [email-masked]
> Subject: RE: NATs as firewalls
> 
> Hallam-Baker, Phillip wrote:
> >>> From: John C Klensin [mailto:[email-masked]]
> >> 
> >>>   And, when I conclude that IPv6 is inevitable (unless 
> someone comes 
> >>> up with another scheme for global unique addresses RSN),
> >> 
> >> Here we disagree, I don't think that IPv6 is inevitable.
> >> When I model the pressures on the various parties in the 
> system and 
> >> consider the shortest route by which the participants can 
> reach their 
> >> short term goals there are certainly alternative schemes.
> >> 
> >> I certainly do not want to see these schemes deployed but they are 
> >> certainly possible outcomes. For example, a hyperNAT where the ISP 
> >> NATs residential Internet as a matter of course. I suspect we will 
> >> start to see this deployed on a large scale as soon as the market 
> >> price for IP address allocation reaches a particular point.
> >> 
> >> There is a major difference between a NAT box plugged into 
> the real 
> >> Internet and a NAT box plugged into another NAT box. It is 
> a pretty 
> >> ugly one for the residential user.
> 
> I'm afraid it is already happening on a large scale in some 
> parts.  Here in Australia I've seen multiple ISP's who NAT 
> all residential customers.  Some of them amongst the largest 
> players in the market.  Even some commercial offerings are on NATs.
> 
> Personally I'm more set against the wholesale blocking of 
> ports and services which ISPs seem to be favouring at the 
> moment, and the pricing that is applied to have the blocks 
> removed.  There are artificial blocks being deployed to keep 
> usage down that are a bigger problem than NATs IMHO.
> 
> Darryl (Dassa) Lynch 
> 
> 
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ietf
> 

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 07 Mar 2007 19:59:22 -0500

On Wednesday, March 07, 2007 04:23:20 PM -0800 "Hallam-Baker, Phillip" 
<[email-masked]> wrote:

> We do need to revise the architecture description. Using IP addresses as
> implicit signalling

You keep using that word.  I do not think it means what you think it means.

> Another instance that hit me today is the
> fact that existing SSL implementations use the server IPv4 address to
> select which server certificate to present to a client.

No; existing SSL server implementations assume that only one certificate is 
relevant for any given transport endpoint.  Which, for the vast majority of 
uses, would not be that big a deal except that a certain vendor which 
dominates the well-known-CA market(*) sees a revenue opportunity in 
wildcard certificates, much as ISP's see a revenue opportunity in 
residential customers who need multiple non-NAT'd addresses.

(*) To be fair, pretty much _every_ vendor does this.

-- Jeff