Subject: RE: Why?

From: [email-masked] (Noel Chiappa)
Date: Sat, 12 Mar 2005 17:12:59 -0500 (EST)

> From: "Michel Py" <[email-masked]>

    > I realize now that this is where we erred: by shifting the
    > multi-homing problem from the ISP to the end-user, we made a
    > less-palatable protocol ...
    > We forgot to KISS. 

I'm going to have to seriously disagree with the philosophical
principle(s) you seem to be promulgating here, because I think you're
quite wrong.

Starting with the more specific principle, moving functionality from "the
network" to "the user entities" is not at all necessarily the Wrong
Thing. Sometimes it's very much the Right Thing.

A classic example is reliability - moving that from the network to the
user entities was definitely the right thing. For another example,
congestion control was also moved from the network to the end entities.
(I know there is still some doubt about the wisdom of this, but we have
made it work, and certainly nobody is talking seriously about moving it
back!)

In analyzing whether moving functionality out to the edges like that is
the right engineering decision, one has to look at a whole range of
factors, and look at the whole system - and sometimes it is indeed the
Right Thing to make the end entities more complex.

More generally, there's TANSTAAFL. We can't expect to build a global
system with all sort of interesting capabilities, and do so with the
same architecture we had when we were planning a much smaller network
with more limited capabilities.

There is going to have to be extra complexity to get those extra
capabilities, and inevitably (for good system architectural reasons, as
discussed above), some of that complexity is going to wind up in the end
entities.

	Noel

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

---

From: Keith Moore <[email-masked]>
Date: Sat, 12 Mar 2005 20:14:10 -0500

> Thing. Sometimes it's very much the Right Thing.

however, when that functionality requires having knowledge that is only 
possessed by the network (which is what hosts need to do address 
selection), moving that functionality all the way to hosts is probably 
the Wrong Thing.  especially when you realize that a lot of the value 
added by IPv6 is the ability to have large numbers of relatively stupid 
hosts (like sensors).

(you might make an argument for moving the functionality to the edge of 
the network, but not all the way to hosts, and that argument might be 
convincing)

Keith

---

From: shogunx <[email-masked]>
Date: Sat, 12 Mar 2005 20:15:58 -0500 (EST)

> added by IPv6 is the ability to have large numbers of relatively stupid

moving it to the CPE routers is the correct solution in my opinion.  of
course, the line blurrs when you use a host as a router, but that is a
different story...

regarding the value add, one would still need a relatively large physical
routing mesh, or a least a stack of hubs, or a wireless access point...
some kind of readily scalable layer 1, to have large numbers of stupid
hosts, though they need not necessarily be sensors.  anyone who has
admin'ed a network of say, beauracrats for example, can readily attest to
this;)

Scott

> the network, but not all the way to hosts, and that argument might be

sleekfreak pirate broadcast
http://sleekfreak.ath.cx:81/

---

From: Bill Manning <[email-masked]>
Date: Sat, 12 Mar 2005 23:07:06 -0800

On Mar 12, 2005, at 17:14, Keith Moore wrote:

> however, when that functionality requires having knowledge that is 
> only possessed by the network (which is what hosts need to do address 
> added by IPv6 is the ability to have large numbers of relatively 
> stupid hosts (like sensors).
>
> (you might make an argument for moving the functionality to the edge 
> of the network, but not all the way to hosts, and that argument might 
> be convincing)
>
	fine... we can move the functionality to the NAT... close to the edge 
but not all the way to the hosts.
	happy now?

---

From: Keith Moore <[email-masked]>
Date: Sun, 13 Mar 2005 11:14:37 -0500

> but not all the way to the hosts.

only if you turn the NAT into something that doesn't do address 
translation for v6.

actually I think we'll end up with something like this in the best 
scenarios - border router will do NAT for IPv4, routing w/o translation 
for v6, security for both.  whether that router tries to finesse 
multihoming for v6 is an open question.

---

From: Terry Gray <[email-masked]>
Date: Sun, 13 Mar 2005 13:53:55 -0800 (Pacific Standard Time)

On Sun, 13 Mar 2005, Keith Moore wrote:

> only if you turn the NAT into something that doesn't do address translation
> for v6.
> 
> actually I think we'll end up with something like this in the best scenarios -
> border router will do NAT for IPv4, routing w/o translation for v6, security
> for both.  whether that router tries to finesse multihoming for v6 is an open
> question.

Keith,
Quick note from the peanut gallery:  I believe your vision is only 
achievable if the address allocation policies for v6 are such that 
every man/woman/child and enterprise can obtain an "ample" amount of 
provider-independent v6 space (or some number of address bits that the 
enterprise can *own*).  If people feel like they are held hostage to 
others for the operation of their internal enterprise (or home!) 
networks, you can take it to the bank that v6 NAT will become just as 
pervasive and entrenched as v4 NAT is.

-teg