Subject: Re: [BEHAVE] Lack of need for 66nat : Long term impact to applicationdevelopers

From: "Eric Klein" <[email-masked]>
Date: Sat, 29 Nov 2008 12:40:38 +0200

On Fri, Nov 28, 2008 at 21:50, Hallam-Baker, Phillip <[email-masked]>wrote:

>
>
> Yes, we all know that it is much easier to get O/S vendors to fix their
> billion plus lines of code and the apps vendors to fix their million plus
> lines of code than it is to deploy a $50 NAT box.
>
> What you are proposing here is that we bell the cat instead.
>

Not necessarily, but it would be nice if we could both have systems that are
not coded badly and networks that are not broken by design.

And I really doubt that the lines of code, in say Vista, that relate to IP
stack and addressed makes up even 0.01% of their code.
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Fred Baker <[email-masked]>
Date: Mon, 1 Dec 2008 01:21:06 -0800

I'll repeat what  said in behave a few days ago. I think this  
capability actually gives the e2e guys (whom I count myself among) 99%  
of what they are looking for while giving rrg-etc, which is to say  
"the ISPs", 99% of what they're looking for.

GSE/8+8 gives us the ability to manage the addresses we exchange in  
routing down to a number of prefixes on the order of (eg equivalent to  
a small multiple of) the number of autonomous systems. PI addressing,  
which is where we are in fact going, gives us a number of prefixes on  
the order of the number of things that want ot attach to the network,  
which is on the order of hundreds of thousands to millions now and  
tens of millions pretty soon, per Marshall Eubanks' analysis for  
NANOG. As specified, it calls for the use of some form of local  
address in the edge networks and a translation to PA at the DMZ  
between the edge and the core.

What the Apps are looking for is a way to connect across the network  
core to provide whatever services they want to provide. If we make  
that hard for them, they will ignore the troubled lower layers and run  
lots of little tubes over the top of the core - and the ISPs will  
suddenly be unable to sell anything other than commodity bandwidth to  
them. Any ISP that has any notion of selling services needs to be very  
aware that making life hard for the applications bites them very hard  
and very fast.

So, what specifically do the applications want? They want a  
predictable address for a machine on the other side of the network  
that they can reach, and they want the junk cleared out of their way.  
They want not just routes that work, but routes that work well. They  
are generally willing to have the addresses underneath them change if  
they can recover from the hit easily.

What they don't want is a lot of excess work, like connection setup  
delays, or large infrastructure they have to manage. If it's the only  
way to accomplish what they want, they will do it, but they would  
actually prefer to get that as a simple service from the network. They  
mostly want to avoid unneeded overheads

Take a look at ftp://ftpeng.cisco.com/fred/gse/nat66-gse.html. What  
I'm working on is what I call the "rendezvous problem", which I  
describe in some detail in section 1.4.1 and test with a vengeance (or  
at least intend to) in the prototype discussed in section 3. I think  
that fundamentally we have to convince or transports that their  
underlying addresses are not a single local and a single peer address,  
but two equivalence classes of addresses. Basically, if we are  
communicating with a remote peer and we receive the next datagram from  
one of the addresses in that peer's equivalence class, we accept it as  
coming from the peer. There are several ways that might be  
accomplished, which I look at in section 2.2 (and if I have missed  
any, I will be happy to have it pointed out to me); they include  
literally building those equivalence classes, and picking up one of  
several identifiers that might act as surrogates for them.

What we need to avoid is knee-jerk thinking. NAT44 has been a real  
disaster from a number of perspectives. I understand why Tony and  
others want to not repeat that. That said, "changing the address in  
flight" doesn't automatically lead to those issues as long as I can  
predictably select the remote host I am interested in and communicate  
with it reliably. What results in those issues is depending on network  
layer addresses exchanged in protocols unrelated to the network layer,  
and the maintenance of ephemeral state at choke points. I want  
stateless translation, and I want higher layer protocols to work with  
names instead of numbers. I like Margaret's NAT66 proposal because it  
enables me to select and route datagrams to a remote host of my  
choosing without huge firewall traversal mechanisms and map/encaps  
databases like LISP proposes, while keeping routing scalable for the  
ISP.

I have been very, very disappointed with the discussion on the topic  
so far. I have gotten to the point of recognizing "I don't want  
translation and I would rather burn books than have it discussed" and  
cutting them off very short. If we can't discuss it, we guarantee that  
we will wind up with the same PI unscalable internet that we have  
today, just with longer addresses, because we guarantee that we will  
make the same mistakes. Either that, or we will make new mistakes that  
are equally bad, like assuming that if we can build a map/encaps  
overlay that shifts the unscalability out of the ISPs we have  
accomplished something of value, when those same ISPs are going to  
have to run the map/encaps databases that the unscalability is  
shuffled off to, or like assuming that making life simple for the ISPs  
by moving the complexity to the edge networks is smart.

No, let's not do that. Let's actually sit down and design something  
that is actually simple and accomplishes the task, which is to  
simultaneously make life straightforward for application designers,  
for those who manage edge networks, and for those that manage ISP  
networks. Let's solve the problem IPv6 set out to solve - to build a  
better next generation network.

I believe that the IESG decided to have this discussion on behave for  
now.
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 1 Dec 2008 22:15:26 +0100

On 1 dec 2008, at 10:21, Fred Baker wrote:

> routing down to a number of prefixes on the order of (eg equivalent  
> to a small multiple of) the number of autonomous systems.

Not really. Or rather, it will, at the following costs:

- all IPv6 implementations must be rewritten
- need an IPv6->GSE transition strategy but unlike v4->v6 addresses  
look the same
- still renumbering necessary when switching ISPs
- identity theft trivial unless we implement id<->locator security  
protocols
- no multihoming without extra protocols to detect and repair failures

See draft-ietf-ipngwg-esd-analysis-05.txt or
http://www.iab.org/about/workshops/routingandaddressing/routingws-gseproblems.pdf

As I've been saying for years: if you fix the problems with GSE, you  
end up with something that looks a lot like shim6.
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Christian Huitema <[email-masked]>
Date: Mon, 1 Dec 2008 19:07:35 -0800

> - no multihoming without extra protocols to detect and repair failures

GSE/8+8 also does not achieve topology hiding, not if the mapping between internal and external /64 is a one-one. Of course, you could smash multiple internal subnets to a single /64 external view, but then you would probably need a new duplicate address detection algorithm to avoid conflicts, not to mention recognize cases of a single host using the same host ID on multiple subnets.

Of course, Iljitsch points an interesting issue. If NAT66 behaves exactly like, say, NAT 64, then why would the organization bother to use IPv6 rather than sticking with net 10?

-- Christian Huitema

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Mon, 1 Dec 2008 22:38:33 -0500

On Mon, 1 Dec 2008 19:07:35 -0800
Christian Huitema <[email-masked]> wrote:

> GSE/8+8 also does not achieve topology hiding, not if the mapping
> between internal and external /64 is a one-one. Of course, you could
> smash multiple internal subnets to a single /64 external view, but
> then you would probably need a new duplicate address detection
> algorithm to avoid conflicts, not to mention recognize cases of a
> single host using the same host ID on multiple subnets.

I'm not sure I believe in the need for topology hiding.  But if I did,
on v6 I'd just allocate a separate subnet or group of subnets for
external access.  If really necessary, have such hosts set up IP over
IP or L2TP tunnels to a concentrator; that will make this external
access net look flat.

> Of course, Iljitsch points an interesting issue. If NAT66 behaves
> exactly like, say, NAT 64, then why would the organization bother to
> use IPv6 rather than sticking with net 10?

Services like Microsoft DirectAccess?

		--Steve Bellovin, http://www.cs.columbia.edu/~smb
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Christian Huitema <[email-masked]>
Date: Mon, 1 Dec 2008 22:41:37 -0800

> IP or L2TP tunnels to a concentrator; that will make this external

That idea has been advanced quite a few times, but there is not a whole lot of code written or products deployed. There are a few interesting issues, e.g. the cost of tunneling versus in terms of overhead or management, or the deployment of adequate source address selection policies.

Actually, rather than tunneling, have we seriously consider flat host based routing in a corporate network? A combination of DHT and caching technologies ought to make that quite scalable.

> Services like Microsoft DirectAccess?

Direct Access certainly does not require that enterprises deploy NAT66...

-- Christian Huitema

---

From: [email-masked]
Date: Tue, 2 Dec 2008 11:37:10 +0000

"I'd just allocate a separate subnet or group of subnets for external access ..."

FWIW - MIPv6 could be used in exactly that fashion.  But this doesn't solve the proposed problem ...

/TJ

Sent from my Verizon Wireless BlackBerry

-----Original Message-----
From: Christian Huitema <[email-masked]>

Date: Mon, 1 Dec 2008 22:41:37 
To: Steven M. Bellovin<[email-masked]>
Cc: Iljitsch van Beijnum<[email-masked]>; Fred Baker<[email-masked]>; IETF Discussion<[email-masked]>
Subject: RE: [BEHAVE] Lack of need for 66nat : Long term	impactto
	applicationdevelopers

-- Christian Huitema

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Tue, 2 Dec 2008 07:53:03 -0500

On Mon, 1 Dec 2008 22:41:37 -0800
Christian Huitema <[email-masked]> wrote:

> Actually, rather than tunneling, have we seriously consider flat host
> based routing in a corporate network? A combination of DHT and
> caching technologies ought to make that quite scalable.

I've used large, flat networks, and lived to regret it....
> > > exactly like, say, NAT 64, then why would the organization bother
> > > to use IPv6 rather than sticking with net 10?
> >
No, but it requires v6 internally.

---

From: "Tony Hain" <[email-masked]>
Date: Tue, 2 Dec 2008 07:21:28 -0800

Christian Huitema wrote:
> That idea has been advanced quite a few times, but there is not a whole
> lot of code written or products deployed. There are a few interesting
> issues, e.g. the cost of tunneling versus in terms of overhead or
> management, or the deployment of adequate source address selection
> policies.

This approach is discussed in 4864 using mIPv6 as the automated tunneling
mechanism to the home agent at the network border. The entire point of
topology hiding is to make all end systems look like they exist at the
network border, and a mIPv6 home agent makes all associated end systems look
like they are hosted from it, and as long as route optimization is blocked
at the firewall the remote system will never see that tunneling is happening
within the corporate network. There is shipping code for home agents and
some for mIPv6 clients. If we could just get a major vendor to ship their
implementation.....

> based routing in a corporate network? A combination of DHT and caching
> technologies ought to make that quite scalable.

4864 does suggest host routes as an alternative, but the 66nat fanatics
refuse to read that section.

Tony

---

From: Christian Huitema <[email-masked]>
Date: Tue, 2 Dec 2008 09:30:31 -0800

> I've used large, flat networks, and lived to regret it....

Do we have a documentation somewhere about the evils of flat networks? Do we know which are links to specific technologies, e.g. the convergence time of spanning trees, and which are tied to the subnet model, e.g. multicast storms? It seems to be a classic case of engineering trade-offs, and mitigation of specific issues...

-- Christian Huitema

---

From: Fred Baker <[email-masked]>
Date: Mon, 1 Dec 2008 21:54:39 -0800

you might take a look at he nat66 document and the behave IPv4/IPv6  
documents. they're pretty different.

---

From: Fred Baker <[email-masked]>
Date: Mon, 1 Dec 2008 23:33:49 -0800

On Dec 1, 2008, at 10:41 PM, Christian Huitema wrote:

> Actually, rather than tunneling, have we seriously consider flat  
> host based routing in a corporate network? A combination of DHT and  

We built a number of networks like those in the 1980's. They were one  
of the best resaons people had to buy Cisco routers at the time - to  
make the large switched backbones work.
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 2 Dec 2008 11:47:01 -0800

Why should anyone care if an internal network is on IPv6 or not? That is probably the silliest part of the NAT66 debate. I am only going to be deploying IPv6 for the few hosts that actually need to receive inbound connections. And I don't expect that to be more than a few hosts on a home network regardless of how much home automation I have.

The only place where we need IPv6 is on the backbone. Folk can run their internal protocols over a transport mechanism of small pyramids with hand engraving performed by a small army of elves for all I care (although I would appreciate a YouTube video of those who are using that mechanism).

If you look at the strategy for the end-of-life for IPv4, surely it will involve placing every network that is not already behind a NAT behind NAT64? As in, the day that IPv4 addresses are no longer being maintained by the NICs and the backbone routers are refusing to accept BGP traffic advertising v4. At that point even NET18 is going to be sequestered behind a NAT because the day that the Internet shuts down IPv4 will come at least 20 years before endpoints stop doing IPv4.

Even if some of my home devices have IPv4, that is not going to be the general case.

If we had assigned five bytes to IPv4 addresses instead of 4 or we had started on a slightly smaller planet, we would not be talking about IPv6 at all, even though 2^40 bytes would clearly be insufficient. Instead we would adopt a two tier architecture and assign IP addresses to networks rather than hosts.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 3 Dec 2008 09:33:55 +0100

On 2 dec 2008, at 20:47, Hallam-Baker, Phillip wrote:

> If you look at the strategy for the end-of-life for IPv4, surely it  
> will involve placing every network that is not already behind a NAT  
> behind NAT64? As in, the day that IPv4 addresses are no longer being  
> maintained by the NICs and the backbone routers are refusing to  
> accept BGP traffic advertising v4.
>

No, that wouldn't work. If hosts still have v4, then routers still  
need to have those prefixes in their tables to get the packets  
delivered. So if you remove the v4 prefixes from routers, you need to  
start routing the IPv6 versions of those prefixes, importing the IPv4  
routing table swamp into the IPv6 routing table, where it takes up  
more room because the addresses are longer. Not a good idea.

What will happen is that as IPv4 traffic becomes a smaller part of the  
total traffic, IPv4 routing will be relegated to older boxes. Just  
like IPv6 routing started on cheaper, separate routers.

You don't really put v4 boxes "behind" NAT64, as NAT64 allows sessions  
in the v6->v4 direction. Rather, you put the IPv4 internet "in front"  
of NAT64.
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Tony Finch <[email-masked]>
Date: Wed, 3 Dec 2008 18:20:09 +0000

On Mon, 1 Dec 2008, Christian Huitema wrote:
>
> have we seriously consider flat host based routing in a corporate
> network? A combination of DHT and caching technologies ought to make
> that quite scalable.

http://100x100network.org/papers/myers-hotnets2004.pdf
"Rethinking the Service Model: Scaling Ethernet to a Million Nodes"

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
SHANNON: WEST OR SOUTHWEST 7 TO SEVERE GALE 9, PERHAPS STORM 10 LATER. ROUGH
OR VERY ROUGH, BECOMING HIGH OR VERY HIGH. RAIN THEN SHOWERS. MODERATE OR
GOOD.
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf