Subject: RE: [midcom] requirements-01 status

From: "Christian Huitema" <[email-masked]>
Date: Fri, 29 Jun 2001 09:11:03 -0700

> From: Bob Penfield [mailto:[email-masked]]
> 
> >I agree with Melinda here. The internal IP packets that are
authorized
> >to sneak through a "pin-hole" will carry an internal source address
and
> >an "external" destination address; the internal routing mechanisms
will
> >direct these packet towards the firewall. If the firewall is to
forward
> >these packets, it will have to do that based solely on the value of
the
> >destination address -- there is no "scope of address" field in the
IPv4
> >packet.  To operate properly, the firewall must have an internal
routing
> >table that maps an IP address to an exit interface. Thus, the
> >"interface" to which an address is bound on a given midcom box has to
be
> >deductible from the IP address itself. Ergo, direction and scope
fields
> >are redundant.
> 
> The middleboxes that I am talking about have no routing tables or
routing
> capability. They sit on a pipe between two routers. Whatever comes in
on
> one
> end of the pipe is sent out the other end. The routers take care of
> sending
> the packets down the right pipe.

Uh? The thing that you describe has essentially no place in the Internet
architecture, and is probably out of scope for this WG.

-- Christian Huitema

_______________________________________________
midcom mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/midcom

---

From: Andrew Molitor <[email-masked]>
Date: Fri, 29 Jun 2001 17:14:18 -0500 (CDT)

> > routing capability. They sit on a pipe between two routers. Whatever
> > comes in on one end of the pipe is sent out the other end. The routers
> > take care of sending the packets down the right pipe.
> 

	It may not have a place in the Internet architecture, and
yet it exists, in many places. Wires, for example, have these properties.
I suppose an approach to dealing with them would be to deny their
existence, and if that failed, to deny their relevance.

	None of these approaches is useful.

	Clearly these devices exist, more will exist in the future,
delivering more capabilities. Clearly it is desirable to standardise
the way in which these devices are controlled, specifically to make
IP telephony work in the real world on a large scale.

	If the IETF has no time, collectively, for these devices,
perhaps you could direct me to a standards body which does, since I'd
just like to get the work done without worrying about the purity
of our architectures. By the way, when did the whole "rough consensus
and running code" thing get replaced by "purity of blood above all, no
goddamn wogs and their bloody stupid ideas" thing, anyways?